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History of CLU 


- The development of CLU began in January 1974. By the summer of 1975, the first version of 
the language had been completed. Over the next two years, the entire language design was 
reviewed and two implementations were produced, Based on this review, and on the experience 
gained in using CLU, a second version of the language was designed in the fall of 1977, and a new 
implementation is now complete. A preliminary version of this manual appeared in July 1978. 
Since that time, an additional statement for exception handling, an own variable mechanism, and 
three new basic type generators have been added to the language, and a number of minor changes 


have been made to the I/O facilities. 
Guide to the Manual 


This document serves both as an introduction to CLU and as a language reference manual. 
Sections | through 4 present an overview of the language. These sections highlight the essential 
features of CLU, and discuss how CLU differs from other, more conventional, languages. Sections 
5 through 13 form the reference manual proper. These sections describe each aspect of CLU in 
detail, and discuss the proper use of various features. Appendices. through III provide concise 
summaries of CLU's syntax, data types, and I/O facilities. Appendix IV contains example 
programs. 

Those readers wanting an introduction to CLU should read Sections 1 through 13 in order, 
concentrating on Sections 1 through 4, 8, 9, and 13. (A brief introduction may be found in 
[Liskov77].) Appendix IV should also be of interest. After becoming familiar with CLU, specific 
questions can be answered by consulting Sections 5 through 13 and Appendices I through III. 

We would greatly appreciate receiving comments on both the language and this manual. 
Comments should be sent to Barbara Liskov, Laboratory for Computer Science, Massachusetts 


Institute of Technology, 545 Technology Square, Cambridge, MA 02139. 


{Liskov77] Liskov, B., Snyder, A., Atkinson, R., and Schaffert, C. Abstraction Mechanisms in 
CLU. Comm. ACM 20, 8 (Aug 1977), 564-576. 
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1. Modules 


A CLU program consists of a group of modules. Three kinds of modules are provided, one 
for each kind of abstraction that we have found to be useful in program construction. Procedures 
support procedural abstraction, iterators support control abstraction, and clusters support data 


abstraction. 
1.1 Procedures 


A procedure performs an action on zero or more argument objects, and terminates returning 
zero or more result objects. All communication between a procedure and its invoker generally takes 
place through these arguments and results; a procedure has no global variables unless it is defined 
in a cluster that has own variables. A procedure may retain objects from one invocation to the 
next through the use of local own variables. 

A procedure may terminate in one of a number of conditions. One of these is the normal 
condition; the others are exceptional conditions. Differing numbers and types of results may be 
returned in different conditions. All information about the names of conditions and the number 
and types of arguments and results is described in the procedure heading. For example, 

square_root = proc (x: real) returns (real signals (no_real_result) 
is. the heading of a square_root procedure, which takes a single real argument. Square_root 
terminates either in the normal condition (returning the square root of x) or in the no_real_result 


condition (returning no results). 
1.2 Iterators 


An iterator computes a sequence of items based on its input arguments. These items are 
provided to its invoker one at a time. Each item consists of zero or more ob jects. 

An iterator is invoked by a for statement. The iterator provides each item by yielding it. The 
objects in the item are assigned to the loop variables of the for statement, and the body of the for 
Statement is executed. Then control is returned to the iterator so it can yield the next item in the 
sequence. The for loop is terminated when the iterator terminates, or the for loop body may 


explicitly terminate itself and the iterator. 
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Just like a procedure, an iterator has no global variables unless it is defined in a cluster that 
has own variables, An iterator may retain objects from one invocation to the next through the use 
of local own variables. An iterator may also terminate in one of a number of conditions. In the 
normal condition, no results can be returned, but different numbers and types of results can be 
returned in the exceptional conditions. All information about the names of conditions, and the 
number and types of arguments and results is described in the iterator heading. For example, 

leaves = iter (t: tree) yields (node) 
is the heading for an iterator that produces all leaf nodes of a tree object. This iterator might be 
used in a for statement as follows: 


for leaf: node in leaves(x) do 
.. CXamine(leaf) ... 
end 


1.3 Clusters 


A cluster implements a data abstraction, which is a set of objects and a set of primitive 
Operations to create and manipulate those objects. The operations can be either procedural or 
control abstractions. The cluster heading states what operations are available, eg., 

int_set = cluster Is create, insert, elements 
States that the operations of int_set are create, insert, and elements. 

A cluster is used to implement a distinct data type, different from all others. Users of this type 
are constrained to treat ob jects of the type abstractly. That is, the objects may be manipulated only 
via the primitive operations. This means that information about how the objects are actually 
represented in storage may not be used. 

Inside the cluster, a concrete representation (in terms of some other type) is chosen for the 
objects, and the operations are implemented in terms of this representation. Each operation is 
implemented by a routine (a procedure or iterator); these routines are exactly like those not 
contained in clusters, except that they can treat the objects being defined by the cluster both 
abstractly and in terms of the concrete representation. (The ability to treat objects abstractly is 
useful when defining recursive data structures, where the concrete representation makes use of the 
new type.) A cluster may contain additional procedures and iterators, which are purely for local 
use; these routines do not define operations of the type. The routines in a cluster are not 


considered to be separate modules; they are simply part of the cluster module. 
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A cluster may also contain own variables, whose lifetimes are independent of routine 
activations. These variables are globally available to all routines in the cluster, but are not 


available from outside the cluster. 
1.4 Parameterized Modules 


Procedures, iterators, and clusters can all be parameterized. Parameterization provides the 
ability to define a class of related abstractions by means of a single module. Parameters are limited 
to the following types: int, real, bool, char, string, null, and type. The most interesting and 
useful of these are the type parameters. 

When a module is parameterized by a type parameter, this implies that the module was written 
without knowledge of what the actual parameter type would be. Nevertheless, if the module is to 
do anything with ob jects of the parameter type, certain operations must be provided by any actual 
type. Information about required operations is described in a where clause, which is part of the 
heading of a parameterized module. For example, 


set = cluster [t: type) is create, insert, elements 
where t has equal: proctype (t, t) returns (boo) 


is the heading of a parameterized cluster defining a generalized set abstraction. Sets of many 
different element types can be obtained from this cluster, but the where clause states that the - 
element type is constrained to provide an egual operation. 

To use a parameterized module, actual values for the parameters must be provided, using the 
general form 

module_name ( parameter_values ] 

Parameter values must be computable at the time they are compiled. Providing actual parameters 
selects one abstraction out of the class of related abstractions defined by the parameterized module; 
since the values are known at compile-time, the compiler can do the selection and can check that 
the where clause restrictions are satisfied. The result of the selection, in the case of a 
parameterized cluster, is a type, which can then be used in declarations; in the case of 
parameterized procedures or iterators, a procedure or iterator is obtained, which is then available 
for invocation. For example, setlint] is a use of the set abstraction shown above, and is legal 


because int does have an equal operation. 
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A parameterized cluster, procedure, or iterator is said to implement a type generator, procedure 


generator, or iterator generator, respectively. 
1.6 Program Structure 


As was mentioned before, a program consists of a group of modules. Each module defines — 
either a single abstraction or, if parameterized, a class of related abstractions. Modules are never 
embedded in other modules. Rather, the program is a single level structure, with all modules 
potentially usable by all other modules in the program. Type-checking of inter-module references 
is carried out using information in the module headings, augmented, in the case of clusters, by the 
headings of the procedures and iterators that implement the operations. 

Each module is a separate textual unit, and is compiled independently of other modules. 


Compilation and program construction are discussed in Section 4. 


2. Data Types 


One of the primary goals of CLU was to provide, through clusters, a type extension © 
mechanism that permits user-defined types to be treated as similarly as possible to built-in types. 
This goal has been achieved to a large extent. Both built-in and user-defined types are viewed as 
providing sets of primitive operations, with access to the real representation information limited to 
just these operations. The ways in which built-in types differ from user-defined types will be 


discussed in Section 2.3 below. 
2.1 Built-in Types 


CLU provides a rich set of built-in types and type generators. The built-in types are int, real, 
bool, char, string, null, and any. Int and real provide the usual arithmetic and relational 
operations on integers and real numbers, and bool provides the standard boolean operations. 
Char is the full ASCII character set; the usual relational operators are provided, along with 
conversion to and from integers. Strings are (possibly empty) sequences of characters; usual string 
operations like selecting the ith character, and concatenation are provided. However, strings are 
somewhat unusual in that string objects cannot be modified. For example, it is not possible to 


change a character in a string; instead, a new string, differing from the original in that position, 
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may be created. 

Null is a type containing one object, nil. Null is used primarily in conjunction with the tagged 
union type discussed below. 

Any is provided to permit an escape from compile-time type-checking. The type any 
introduces no new objects, but instead may be used as the type of a variable when the programmer 
wishes to assign objects of different types to that variable, or does not know what kind of object 
will be assigned to the variable. CLU provides a built-in procedure generator, force, which 
permits a run-time examination of the type of object named by a variable of type any. 

The built-in type generators are: array, sequence, record, struct, oneof, variant, 
proctype, and itertype. Arrays are one-dimensional. The type of element contained in the array 
is specified by a type parameter, eg., arraylint]) and arraylarraylint)). (The latter example 
shows how a two-dimensional array might be handled.) CLU arrays are unusual in that they can 
grow dynamically. An array is often empty when first created, but there is also a special array 
constructor for specifying initial elements. Array operations can grow and shrink the array at 
either end, query the current size and low and high bounds of the array, and access and replace 
elements within the current bounds. 

Sequences are immutable arrays, in that the size of a sequence can not be changed dynamically, 
and new elements cannot be stored into a sequence. New sequences can be constructed from | 
existing sequences in much the same way as new strings are created. Sequence operations are culled 
from both string and array operations, and there is a special sequence constructor, which is 
syntactically similar to the array constructor form. 

CLU records are heterogeneous collections of component ob jects; each component is accessed by 
a selector name. Records must be explicitly constructed by means of a special record constructor. 
The constructor requires that an object be provided for each component of the record; this 
_ requirement ensures that no component of the record is undefined in the sense of naming no 
object. Record operations permit selection of component objects and replacement of components 
with new ob jects. 

Structures are immutable records, in that the components of a structure cannot be replaced with 
new ob jects. Structures are constructed by means of a structure constructor, which is syntactically 


identical to the record constructor form. 
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A oneof type is a tagged, discriminated union. The objects of a oneof type each consist of a 
tag (an identifier) and a component object; oneof objects with different tags may have component 
objects of different types. A oneof object, once created, cannot be changed. Thus, oneof types 
provide a capability similar to that provided by variant records in Pascal. Operations are 
provided for creating oneof objects. Oneof objects are usually decomposed through the tagcase 
statement. . 

Variants are mutable oneofs. The tag and component object of a variant can be replaced 
simultaneously with new values. Like oneofs, variants are usually decomposed through the 
tagcase statement. 

Procedure and iterator types provide procedures and iterators as first-class ob jects; i.e., routines 
(including those in clusters) can be assigned to variables and can occur as components of other 
ob jects. These types are parameterized by all the information appearing in a procedure or iterator 
heading, with the exception of the formal argument names. 

In addition to all the built-in types and type generators mentioned above, CLU programs may 
also make use of the type type. The use of type values is limited to parameters of parameterized 
modules; there are no arguments or variables of type type. 

Finally, CLU provides a number of types and procedures to support I/O. These types are not 
considered to be built-in types of CLU, but they must be available in the library. These types are 
described in Appendix IIT. 


2.2 User-Defined Types 


Users may define new types by providing clusters that implement them. The cluster may 
implement a single type, or, in the case of a parameterized cluster, a group of related types. The 
type or types defined by a cluster are distinct from all built-in types and from all types defined by 


other clusters. 
2.3 Comparison of User-Defined and Built-In Types 


Little distinction is made between user-defined types and built-in types. Either can be used 
freely to declare the arguments, variables, and results of routines. In addition, in either case there 
is a set of primitive operations associated with the type, and the same syntax is used to invoke these 


operations. The ordinary syntax to name an operation is 
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type $ op_name 
Since different types will often have operations of the same name (e.g., create), this compound form 
is used to avoid ambiguity. 

For many operations there is also a customary abbreviated form of invocation, which can be 
used for user-defined types as well as for built-in types. There is a standard translation from each 
abbreviated form to the ordinary form of invocation. For example, an addition operation is 
usually invoked using the infix notation "x + y"; this is translated into “"T$add(x, y)", where T is 
the type of x. Extending notation to user-defined types in this way is sometimes called operator 
overloading. We permit almost all special syntax to be overloaded; there are always constraints on 
the overloading definition (e.g., add must have two input arguments and one result), but they are 
quite minimal. 

Nevertheless, there are three main distinctions between built-in types and user-defined types: 


1. Built-in type and type generator names cannot be redefined. (This is 
why we always show them in boldface in this document.) 


2. Some built-in types, eg., int, real, etc., have literals. There is no 
mechanism for defining literals for user-defined types. 


3. Some built-in types are related to certain other constructs of CLU. For 
example, the tagcase statement is a control construct especially 
provided to permit discrimination on oneof and variant objects. In 
addition, in places where compile-time constants are required, e.g., as 
actual parameters to parameterized modules, the expressions that may 
appear are limited to a subset of the built-in types and their operations. 
One reason for this limitation is that the permitted types are known to 
contain only immutable ob jects (see Section 3.1). 


3. Semantics 


All languages present their users with some model of computation. This section describes those 
aspects of CLU semantics that differ from the common ALGOL-like model. In particular, we 
discuss the notions of objects and variables, and the definitions of assignment and argument 


passing that follow from these notions. We also discuss type-correctness. 
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3.1 Objects and Variables 


The basic elements of CLU semantics are objects and variables. Objects are the data entities 
that are created and manipulated by programs. Variables are just the names used in a program to 
refer to ob jects. 

Each object has a type, which characterizes its behavior. A type defines a set of primitive 
operations to create and manipulate objects of that type. An object may be created and 
manipulated only via the operations of its type. 

An object may refer to objects. For example, a record object refers to the objects that are the 
components of the record. This notion is one of logical, not physical, containment. In particular, it 
is possible for two distinct record objects to refer to (or share) the same component object. In the 
case of a cyclic data structure, it is even possible for an object to “contain” itself. Thus, it is 
possible to have recursive data structure definitions and shared data objects without explicit 
reference types. 

Objects exist independently of procedure and iterator activations. Space for objects is 
allocated from a dynamic storage area as the result of invoking constructor operations of certain 
primitive CLU types, such as records and arrays. In theory, all objects continue to exist forever. 
In practice, the space used by an object may be reclaimed (via garbage collection) when that ob ject 
is no longer accessible. (An ob ject is accessible if it is denoted by a variable of an active routine or 
an own variable of any cluster or routine, or is a component of an accessible ob ject.) 

Ob jects may be divided into two categories. Some objects exhibit time-varying behavior. 
Such an object, called a mutable object, has a state that may be modified by certain operations 
without changing the identity of the object. Records and arrays are examples of mutable ob jects. 
For example, replacing the ith element of any array a@ causes the state of a to change (to contain a 
different ob ject as the ith element). 

If a mutable object m is shared by two other objects x and y, then a modification to m made 
via x will be visible when m is examined via y. Communication through shared mutable ob jects is 
most beneficial in the context of procedure invocation, described below. 

Objects that do not exhibit time-varying behavior are called immutable objects. Examples of 
immutable objects are integers, booleans, characters, and strings. The properties of an immutable 
object do not change with time. These properties generally do not include the properties of any 


component objects. For example, a sequence is immutable even though its elements may be 


14 Ob jects and Variables §3.1 


mutable. 

Variables are names used in programs to denote particular objects at execution time. Unlike 
variables in many common programming languages, which are containers for values, CLU 
variables are simply names that the programmer uses to refer to objects. As such, it is possible for 
two variables to denote (or share) the same object. CLU variables are much like those in LISP, 
and are similar to pointer variables in other languages. However, CLU variables are not ob jects; 
they cannot be denoted by other variables or referred to by objects. Thus, variables declared 


within one routine cannot be accessed or modified by any other routine. 
3.2 Assignment and Invocation 


The basic actions in CLU are assignment and invocation. The assignment primitive x := E, 
where x is a variable and E is an expression, causes x to denote the object resulting from the 
evaluation of E. For example, if E is a simple variable 9, then the assignment x := 9 causes x to 
denote the object denoted by y. The object is not copied; after the assignment is performed, the 
ob ject will be shared by x and . Assignment does not affect the state of any ob ject. 

Figure | illustrates these notions of object, variable, and assignment. Here we show variables 
in a stack, and objects in a heap (free storage area), an obvious way to implement CLU. Figure la _ 
contains three ob jects: a, 8, and y. @ is an integer (in fact, 3) and is denoted by variable x, while 8 
and ¥ are of type set{int] and are denoted by variables y and z, respectively. Figure lb shows the 
result of executing 

yi=2Z 
Now y and z both refer to, or share, the same object, y; 8 is no longer accessible, and so can be 
garbage collected. 

Invocation involves passing argument objects from the caller to the called routine and 
returning result objects from the routine to the caller. The objects returned by the procedure, or 
yielded by an iterator, may be assigned to variables in the caller. Argument passing is defined in 
terms of assignment; the formal arguments of a routine are considered to be local variables of the 
routine and are initialized, by assignment, to the objects resulting from the evaluation of the 
argument expressions. We call the argument passing technique call by sharing, because the 
argument objects are shared between the caller and the called routine. The technique does not 
correspond to most traditional argument passing techniques (it is similar to argument passing in 


LISP). In particular it is not call by value because mutations of arguments performed by the called 
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Fig. 1. Assignment 


routine will be visible to the caller. And it is not call by reference because access is not given to the 
variables of the caller, but merely to certain ob jects. 

Figure 2 illustrates invocation and object mutation. Figure 2a continues from the situation 
shown in Figure 1b, and illustrates the situation immediately after invocation of 

setLint]$insertly, x) 

(but before executing the body of insert). Insert has two formal arguments; the first, s, denotes the 
set, and the second, v, denotes the integer to be inserted into s. Note that the variables of the caller 
(x, y and, z) are not accessible to insert. Figure 2b illustrates the situation after insert returns. Note 
that object y has been modified and now refers to @ (the set y now contains 3), and since ¥ is 
shared by both y and z, the modification of ¥ is visible through both these variables. 

Procedure invocations may be used directly as statements; those that return exactly one ob ject 
may also be used as expressions. Iterators may be invoked only through the for statement. 


Arbitrary recursion among procedures and iterators is permitted. 
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Fig. 2. Invocation and ob ject mutation 


Fig 2a. 


Fig 2b. 


3.3  Type-Correctness 


The declaration of a variable specifies the type of the objects which the variable may denote. 
In an assignment, the object denoted by the right-hand side must have the same type as the 
variable on the left-hand side: there are no implicit type conversions. (The type of ob ject denoted 
by an expression is the return type of the outermost procedure invoked in that expression, or, if the 
expression is a variable or literal, the type of that variable or literal.) There is one special case; a 
variable declared to be of type any may be assigned the value of any expression. 

Argument passing is defined in terms of assignment; for an invocation to be legal, it must be 
possible to assign the actual arguments (the objects) to the formal arguments (the variables) listed 
in the heading of the routine to be invoked. Furthermore, a return (or yleld) statement is legal 
only if the result objects could be legally assigned to variables having the types stated in the 


routine heading. 
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CLU is a type-safe language, in that it is not possible to treat an object of type T as if it were 
an object of some other type S; in particular, one cannot assign an object of type T to a variable of 
type S (unless S is any). The type any provides an escape from compile-time type determination, 
and a built-in procedure generator force can be used query the type of an object at run-time. 
However, any and force are defined in such a way that the type-safety of the language is not 
undermined. The type-safety of CLU, plus the restriction that only the code in a cluster may 
convert between the abstract type and the concrete representation, insure that the behavior of an 


ob ject is indeed characterized completely by the operations of its type. 


4. The Library 


As was mentioned earlier, it is intended that the modules making up a program all be separate 
compilation units. A fundamental requirement of any CLU implementation is that it support 
separate compilation, with type-checking of inter-module references. This checking can be done 
either at compile-time or at load-time (when a group of separately compiled modules are combined 
together to form a program). A second fundamental requirement is that the implementation 
support top-down programming. The definition of CLU does not specif y how an implementation 
should meet these requirements. However, in this section we describe the current CLU 
implementation, which may serve as a model for others. 

Our implementation makes use of the CLU library, which plays a central role in supporting 
inter-module references. The library contains information about all abstractions. It supports 
incremental program development, one abstraction at a time, and, in addition, makes abstractions 
that are defined during the construction of one program available as a basis for subsequent 
program development. The information in the library permits the separate compilation of single 
modules, with complete type-checking at compile-time of all external references (such as procedure 
names). 

The library provides a hierarchical name space for retrieving information about abstractions. 
The leaf nodes of the library are description units (DUs), one for each abstraction. Figure 3 


illustrates the structure of the library. 
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Fig. 3. A sketch of the library structure showing a DU with pathname B.Y 


A DU contains all system-maintained information about its abstraction. A sketch of the 
structure of a DU is shown in Figure 4. For purposes of program development and module 
compilation, two pieces of information must be included in the DU: implementation information, 
describing zero or more modules that implement the abstraction, and the interface specification. 
The interface specification is that information needed to type-check uses of the abstraction. For 
procedural and control abstractions, this information consists of the number and types of 
parameters, arguments, and results, the names of exceptional conditions and the number and types 
of results returned in each case, plus any constraints on type parameters (i.e., the where clause, as 


described in Section 1.4). For data abstractions, it includes the number and types of parameters, 


Fig. 4. A sketch showing the structure of a DU 


(ou) 


interface abstractions implementations other 
specification used in : information 
interface 


source object abstractions other 
code code used in information 
implementation 
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constraints on type parameters, and the name and interface specif ication of each operation. 

An abstraction is entered in the library by submitting the interface specification; no 
implementations are required. In fact, a module can be compiled before any implementations have 
been provided for the abstractions that it uses; it is necessary only that interface specifications have 
been given for those abstractions. Ultimately, there can be many implementations of an 
abstraction; each implementation is required to satisfy the interface specification of the abstraction. 
Because all uses and implementations of an abstraction are checked against the interface 
specification, the actual selection of an implementation can be delayed until just before (or perhaps 
during) execution. We imagine a process of binding together modules into programs, prior to 
execution, at which time this selection would be made. 

An important detail is the method by which modules refer to abstractions. To avoid the 
problems of name conf licts that can arise in large systems, the names used by a module to refer to 
abstractions can be chosen to suit the programmer's convenience. When a module is submitted for 
compilation, its external references must be bound to DUs so that type-checking can be performed. 
The binding is accomplished by constructing a compilation environment (CE), mapping names to 
DUs and constants, which is passed to the compiler along with the source code when compiling the 
module. A copy of the CE is stored by the compiler in the library as part of the module. A similar 
process is involved in entering interface specifications of abstractions, since these interfaces can 
include references to other (data) abstractions. 

When the compiler type-checks a module, it uses the compilation environment to map the 
external names in the module to constants and DUs, and then uses the interface specifications in 
the referenced DUs to check that the abstractions are used correctly. The type-correctness of the 
module thus depends upon the binding of external references and the interface specifications of all 
referenced DUs, and could be invalidated if changes to the binding or the interface specifications 
were subsequently made. For this reason, the process of compilation permanently binds a module to 
the abstractions it uses, and the interface specification of an abstraction, once defined, is not 
allowed to change. Of course, a new DU can be created to describe a modified abstraction. 
Furthermore, during design (before any implementing modules have been entered into the system) 
it is reasonable to permit abstraction interfaces to change. 

Typicatly a small to medium sized project will use only one CE, thereby establishing a 
consistent vocabulary for use by all programmers. Larger projects might have a number of 


(possibly “overlapping”) CEs, each specialized for some subpro ject. 


20 The Library §4 


The library and DU structure described above can be used for purposes other than compiling 
and loading programs. In each case, additional information can be stored in the DU; the “other” 
fields shown in Figure 4 are intended to illustrate such additional information. For example, the 
library provides a good basis for program verification. Here the “other” information in the DU 
would contain a formal specification of the abstraction, and possibly some theorems that had been 
proved about the abstraction, while for each implementation that had been verified, an outline of 
the correctness proof might be retained. Additional uses of the library include retention of 
debugging and optimization information. 


5S. Notation 


We use an extended BNF grammar to define the syntax. The general form of a production is: 


nonterminal ::z akernative 
| akternative 


| one 


| akernative 
The following extensions are used: 
ere a list of one or more a's separated by commas: "a" or “a, a” or 
a,a,a” etc. 
{a} a sequence of zero or more a's: ”” or “a” or "a a” etc. 


[a] an optional a: °” or “a”. 
Nonterminal symbols appear in normal face. Reserved words appear in bold face. All other 
terminal symbols are non-alphabetic, and appear in normal face. | 
Full productions are not always shown in the body of this manual often alternatives are 
presented and explained individually. Appendix | contains the complete syntax. 
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6. Lexical Considerations 


A module is written as a sequence of tokens and separators. A foken is a sequence of “printing” 
ASCII characters (octal value 40 thru 176) representing a reserved word, an identifier, a literal, an 
operator, or a punctuation symbol. A separator is a “blank” character (space, vertical tab, horizontal 
tab, carriage return, newline, form feed) or a comment. In general, any number of separators may 


appear between tokens. Tokens and separators are described in more detail in the sections below. 


6.1 Reserved Words 


The following character sequences are reserved words: 


any cvt force oneof returns true 
array do has others sequence type 
begin down if own signal up 

bool else in proc signals variant 
break elseif int proctype string when 
cand end is real struct where 
char except iter record tag while 
cluster exit itertype rep tagcase yield 
continue false nil resignal then yields 
cor for null return 


Upper and lower case letters are not distinguished in reserved words. For example, ‘end’, END’, 


and ‘eNd’ are all the same reserved word. Reserved words appear in bold face in this document. 
6.2 Identifiers 


An identifier is a sequence of letters, digits, and underscores that begins with a letter or 
underscore, and that is not a reserved word. As in reserved words, upper and lower case letters are 
not distinguished in identifiers. 

In the syntax there are two diff erent nonterminals for identifiers. The nonterminal idn is used 
when the identifier has scope (see Section 8.1); idns are used for variables, parameters, module 
names, and as abbreviations for constants. The nonterminal name is used when the identifier is 
not sub ject to scope rules; names are used for record and structure selectors, oneof and variant tags, 


operation names, and exceptional condition names. 
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6.3. Literals 


There are literals for naming objects of the built-in types null, bool, int, real, char, and 


string. Their forms are discussed in Section 7. 
6.4 Operators and Punctuation Symbols 


The following character sequences are used as operators and punctuation symbols: 


( : <= wen - st 
) ¥ = ve s // 
: >a ~>= / & 
if $ > ~> | 
< ~< + ] 


6.5 Comments and Other Separators 


A comment is a sequence of characters that begins with a percent sign (x), ends with a newline 
character, and contains only printing ASCII characters and horizontal tabs in between. For 
example: 


z := ali] + % a comment in an expression 
bli) 


A separator is a blank character (space, vertical tab, horizontal tab, carriage return, newline, 
form feed) or a comment. Zero or more separators may appear between any two tokens, except that 
at least one separator is required between any two adjacent non-self-terminating tokens: reserved 
words, identifiers, integer literals, and real literals. This rule is necessary to avoid lexical 


ambiguities. 
6.6 Semicolons 


The use of semicolons (;) to terminate statements and various phrases is permitted in CLU, but 
semicolons are completely optional and their use is discouraged. Placement of semicolons is not 


shown in the body of this manual; refer to the complete syntax in Appendix I. 
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7. Types, Type Generators, and Type Specifications 


A type consists of a set of objects together with a set of operations to manipulate the ob jects. 
As discussed in Section 3.1, types can be classified according to whether their ob jects are mutable or 
immutable. An immutable object (e.g, an integer) has a value that never varies, while the value 
(state) of a mutable ob ject can vary over time. 

A type generator is a parameterized type definition, representing a (usually infinite) set of 
related types. A particular type is obtained from a type generator by writing the generator name 
along with specific values for the parameters; for every distinct set of legal values, a distinct type is 
obtained. For example, the array type generator has a single parameter that determines the 
element type; arraylintl, arraylreal], and arraylarraylint)) are three distinct types defined by 
the array type generator. Types obtained from type generators are called parameterized types; 
others are called simple types. 

Within a program, a type is specified by a syntactic construct called a type_spec. The type 
specification for a simple type is just the identifier (or reserved word) naming the type. For 
parameterized types, the type specification consists of the identifier (or reserved word) naming the 
type generator, together with the parameter values. 

This section gives an informal introduction to the built-in types and type generators provided 
by CLU; many details (such as error conditions) are not discussed. Complete and precise 
definitions are given in Appendix II. Sections 7.1 to 7.7 describe the objects, literals, and some of 
the operations for each of the built-in types, while Sections 7.8 to 7.14 describe the ob jects, type 
specifications, and interesting operations of types obtained from the built-in type generators. A 
number of operations can be invoked using infix and prefix operators; as the various operation 
names are introduced, the corresponding operator, if any, will follow in parentheses. 

In addition, we describe type specifications for user-defined types, and other special type 
Specifications in Section 7.15. The mechanism by which new types and type generators are 


implemented is presented in Section 13. 
7.1 Null 


The type null has exactly one immutable object, represented by the literal nil. The type null is 


generally used as a kind of “place filler” in a oneof or variant type (see Sections 7.12 and 7.13). 
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7.2 Bool 


The two immutable objects of type bool, with literals true and false, represent logical truth 
values. The binary operations equal (=), and (&), and or (I), are provided, as well as unary not (~). 


7.3 Int 


The type int models (a range of) the mathematical integers. The exact range is not part of the 
language definition, and can vary somewhat from implementation to implementation (see 
Appendix II, Section 3). Integers are immutable, and are written as a sequence of one or more 
decimal digits. The binary operations add (+), sub (-), mul (s), div (/), mod (//), and power (¢#) are 
provided, as well as unary minus (-). There are binary comparison operations /f (<), le (<=), equal 
(=), ge (>=), and gf (>). In addition, there are two operations, from_to and from_to_by, for iterating 
over a sequence of integers. For example, one can iterate over the odd numbers between 1 and 100 
with 

for i: int in int$from_to_by(1, 100, 2) do ...compute... end 


7.4 Real 


The type real models (a subset of) the mathematical real numbers. The exact subset is not | 
part of the language definition, although certain constraints are imposed (see Appendix HI, 
Section 4). Reals are immutable, and are written as a mantissa with an (optional) exponent. A 
mantissa is either a sequence of one or more decimal digits, or two sequences (one of which may be 
empty) joined by a period. The mantissa must contain at least one digit. An exponent is ’E’ or ‘e’, 
optionally followed by ‘+’ or ’-’, followed by one or more decimal digits. An exponent is required if 
the mantissa does not contain a period. As is usual, mEx = ms10*. Examples of real literals are: 

3.14 3.14E0 314e-2 O314E+2 3. 14 

As with integers, the operations add (+), sub (-), mul (s), div (/), mod (//), power (s#), minus (-), 
lt (<), le (<=), equal (=), ge (>=), and gt (>), are provided. It is important to note that there is no 
form of implicit conversion between types. So, for example, the various binary operators cannot 
have one integer and one real argument. The i2r operation converts an integer to a real, r2i 


rounds a real to an integer, and trunc truncates a real to an integer. 
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7.6 Char 


The type char provides the alphabet for text manipulation. Characters are immutable, and 
form an ordered set. Every implementation must provide at least 128, but no more than 512, 
characters; the first 128 characters are the ASCII characters in their standard order. 

Printing ASCII characters (octal 40 thru octal 176), other than single quote or backslash, can be 
written as that character enclosed in single quotes. Any character can be written by enclosing one 


of the following escape sequences in single quotes: 


escape sequence character 


\' * (single quote) 

As "(double quote) 

\\ \ (backslash) 

\n NL (newline) 

Nt HT (horizontal tab) 

\p FF (form feed, newpage) 

\b BS (backspace) 

\rv CR (carriage return) 

\v oF VT (vertical tab) 

\te8 \. specified by octal value (exactly three octal digits) 


The escape sequences may be written using upper case letters. Examples of character literals are: 
a ‘a ae a Vv \B’ MTT 
There are two operations, i2c and c2i, for converting between integers and characters: the 
smallest character corresponds to zero, and the characters are numbered sequentially. Binary 
comparison operations exist for characters based on this numerical ordering: lt (<), le (<=), equal (=), 


ge (>=), and gt (>). 
7.6 String 


The type string is used for representing text. A string is an immutable sequence of zero or 
more characters. Strings are lexicographically ordered, based on the ordering for characters. A 
string is written as a sequence of zero or more character representations, enclosed in double quotes. 
Within a string literal, a printing ASCII character other than double quote or backslash is 
represented by itself. Any character can be represented by using the escape sequences listed above. 
Examples of string literals are: 

"Item\tCost” “altmode (\033) = \\033" me woe 
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The characters of a string are indexed sequentially starting from one, and there are a number 
of operations that deal with these indexes: fetch, substr, rest, indexc, and indexs. The fetch 
Operation is used to obtain a character by index. Invocations of fetch can be written using a special 
syntax (fully described in Section 10.5.1): . 

sti] % get the character at index i of s 
Substr returns a string given a string, a starting index, and a length: 
string$substr("abcde”, 2, 9) = “bcd” 
Rest, given a string and a starting index, returns the rest of the string: 
string$rest("abcde”, $) = “cde” 
Indexc computes the least index at which a character occurs in a string, and indexs does the same 
for a string; the result is 2ero if the character or string does not occur: 


string$indexc('d’, “abcde” = 4 
string$ indexs("cd", “abcde” = 3 
string$ indexs("abcde”, “cd” = 0 


Two strings can be concatenated together with concet (W, and a single character can be 
appended to the end of a string with append. Note that stringSconcat("abc’, "de" and 
stringSappend(“abcd", ‘e? produce the same string as writing “abcde”. C2s converts a character to 
a single-character string. The size of a string can be determined with size. Chars iterates over the 
characters of a string, from the first to the fast character. There are also the usual lexicographic 
comparison operations: it (<), le (<=), equal (=), ge (>=), and gt (>). 


7.7 Any 


A type specification is used to restrict the class of objects that a variable can denote, a 
procedure or iterator can take as arguments, a procedure can return, etc. There are times when no 
restrictions are desired, when any ob ject is acceptable. At such times, the type specification any is 
used. For example, one might wish to implement a table mapping strings to arbitrary ob jects, with 
the intention that different strings could map to objects of different types. The lookup operation, 
used to get the object corresponding to a string, would have its resuk declared to be of type any. 

The type any is the union of all possible types, and it is the only true union type in CLU; all 
other types are base types. Every object is of type any, as well as being of some base type. The 
type any has no operations; however, the base type of an object can be tested at run-time (see 
Section 10.1). 
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7.8 Array Types 


Arrays are one-dimensional, and are mutable. Arrays are unconventional because the number 
of elements in an array can vary dynamically. Furthermore, there is no notion of an “uninitialized” 
element. 

The state of an array consists of an integer called the low bound, and a sequence of ob jects 
called the elements. The elements of an array are indexed sequentially, starting from the low 
bound. All of the elements must be of the same type; this type is specified in the array type 
Specification, which has the form 

array [ type_spec ] 
Examples of array type specifications are 


arraylint) 
arrayl array(string)] 


There are a number of ways to create a new array, of which only two are mentioned here. 
The create operation takes an argument specifying the low bound, and creates a new array with 
that low bound and no elements. An array constructor can be used to create an array with an 
arbitrary number of initial elements. For example, 

arraylint) $ (5: 1, 2, 3, 4] 
creates an integer array with low bound 5, and four elements, while 

arrayl bool] $ (true, faise] 
creates a boolean array with low bound | (the default), and two elements. Array constructors are 
discussed fully in Section 10.6.1. 

An array type specification states nothing about the bounds of an array. This is because 
arrays can grow and shrink dynamically. Addh adds an additional element to the end of the array, 
with index one greater than the previous last element. Add! adds an additional element to the 
beginning of the array, and decrements the low bound by one, so that the new first element has an 
index one less than the previous first element. Remh removes the last element; rem! removes the 
first element and increments the low bound. Note that all of these operations preserve the indexes 
of the other elements. Also note that these operations do not create holes; they merely add to or 
remove from the ends of the array. 

As an example, if a remh were performed on the integer array 

arraylint) $ [5: 1, 2, 3, 4) 


the element 4 would disappear, and the new last element would be 3, still with index 7. If a 0 were 


28 Array Types §7.8 


added using addi, it would become the new first element, with index 4. 

The fetch operation extracts an element by index, and the store operation replaces an element 
by index; an index is illegal if no element with that index exists. Invocations of these operations 
can be written using special forms (covered fully in Sections 10.5.1 and 11.2.0: 


ali} % fetch the element at index i of a 
ali) := 3 % store 3 at index i of a (not really assignment) 


The top and bottom operations return the element with the highest and lowest index, 
respectively. The Aigh and low operations return the highest and lowest indexes, respectively. The 
elements iterator yields the elements from bottom to top, and the indexes iterator yields the indexes 
from low to high. There is also a size operation that returns the number of elements. 

Every newly created array has an identity that is distinct from all other arrays; two arrays can 
have the same elements without being the same array object. The identity of arrays can be 
distinguished with the equal (=) operation. The similar] operation tests if two arrays have the 
Same state, using the equal operation of the element type. Similar tests if two arrays have similar 
States, using the similar operation of the element type. For example, writing 

ai$f3; 1, 2, 3] 
(where “ai” is equated to arraylint)) in different places produces arrays that are similarl and 
Similar (but not equal), while the following produces arrays that are similar, but not similar! (or. 
equal): 

arraylai] $ [1: ai$create(1)) 


7.8 Sequence Types 


Sequences are immutable arrays. Although an individual sequence can have any length, that 
length cannot vary dynamically, and the elements of the sequence cannot be replaced. The elements 
of a sequence are indexed sequentially, starting from one. A sequence type specification has the 
form 

sequence [ type_spec ] 

The new operation returns an empty sequence. A sequence constructor, which is syntactically 

similar to the array constructor, can be used to create a sequence with an arbitrary number of 


elements. Sequence constructors are discussed fully in Section 10.6.2. 
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Although a sequence, once created, cannot be changed, new sequences can be constructed from 
existing ones. Addh creates a new sequence with an additional element at the end (with index one 
greater than the last element of the old sequence). Addi creates a new sequence with an additional 
element at the beginning, with index one, so that every other element has an index one greater 
than its index in the old sequence. Remh creates a new sequence with the last element removed; 
reml creates a new sequence with the first element removed. Note that, for each of these operations, 
element ob jects are shared between the old and new sequences. 

The fetch operation extracts an element by index, and the replace operation creates a new 
sequence with a new element at a given index; an index is illegal if no element with that index 
exists. Invocations of the fetch operation can be written using a special form (covered fully in 
Section 10.5.1): | 

qi} % fetch the element at index i of q 

The top and bottom operations return the element with the highest and fowest index, 
respectively. The size operation returns the number of elements. The elements iterator yields the 
elements from bottom to top, and the indexes iterator yields the indexes in increasing order, starting 
from one. Two sequences can be concatenated together with concat (Il) to produce a new sequence, 
and subseq extracts a subsequence of a sequence. 

Two sequences with the same elements are the same sequence. The equal (<) operation tests if 
two sequences have the same elements, using the equal operation of the element type. Similar tests 
if two sequences have similar elements, using the similar operation of the element type. For 
example, writing 

sequencel array(int))${ arraylint)$(1}) 


in different places produces sequences that are similar but not equal. 
7.10 Record Types 


A record is a mutable collection of one or more named objects. The names are called selectors, 
and the objects are called components. Different components may have different types. A record 
type specification has the form 

record [ field_spec, ... J 
where 
field_spec ::= mame, ... : type_spec 


Selectors must be unique within a specification, but the ordering and grouping of selectors is 
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unimportant. For example, all the of the following name the same type: 


record{last, first, middle: string, age: int) 
record first, middle, last: string, age: Int) 
record.last: string, age: int, first, middle: string) 


A record is created using a record constructor. For example: 
info $ {last: “Jones”, first: “John”, age: 32, middle: "J."} 
(assuming that “info” has been equated to one of the above type specifications; see Section 8.3). An 
expression must be given for each selector, but the order and grouping of selectors need not 
resemble the corresponding type specification. Record constructors are discussed fully in 
Section 10.6.3. 

For each selector “sel”, there is an operation get_sel to extract the named component, and an 
operation set_sel to replace the named component with some other object. For example, there are 
get_middle and set_middle operations for the type specified above. Invocations of these operations 
can be written in a special form (discussed fully in Sections 10.5.2 and 11.2.2): 


r.middle % get the ‘middle’ component of r 
rage := 33 % set the ‘age’ component of r to 33 (not really assignment) 


As with arrays, every newly created record has an identity that is distinct from all other 
records; two records can have the same components without being the same record object. The 
identity of records can be distinguished with the equal (=) operation. The similar! operation tests . 
if two records have the same components, using the equal operations of the component types. 
Similar tests if two records have similar components, using the similar operations of the component 


types. 


7.11 Structure Types 


A structure is an immutable record. A structure type specification has the form 
struct [ field_spec,... ] 
where (as for records) 
field_spec ::= name, ... : type_spec 
A structure is created using a structure constructor, which syntactically is identical to a record 
constructor. Structure constructors are discussed fully in Section 10.6.4. 
For each selector “sel”, there is an operation get_sel to extract the named component, and an 
operation replace_sel to create a new structure with the named component replaced with some other 


ob ject. Invocations of the get operations can be written in a special form (discussed fully in 
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Section 10.5.2): 
st.seldom % get the ‘seldom’ component of st 
As with sequences, two structures with the same components are in fact the same object. The 
equal (=) operation tests if two structures. have the same components, using the equal operations of 
the component types. Similar tests if two structures have similar components, using the similar 


operations of the component types. 
7.12 Oneof Types 


A oneof type is a tagged discriminated union. A oneof is an immutable labeled ob ject, to be 
thought of as “one of” a set of alternatives. The label is called the tag, and the ob ject is called the 
value. A oneof type specification has the form 

oneof [ field_spec , ... ] 
where (as for records) 
field_spec ::= name, ... : type_spec 
Tags must be unique within a specification, but the ordering and grouping of tags is unimportant. 

As an example of a oneof type, the representation type for an immutable linked list of integers, 

int_list, might be written . 


oneoflempty: null, 
pair: structicar: int, cdr: int_list]) 


As another example, the contents of a “number container” might be specified by 


oneoflempty: null, 
integer: int, 
real_num: real, 


complex_num: complex] 

For each tag “t” of a oneof type, there is a make_t operation which takes an ob ject of the type 

associated with the tag, and returns the ob ject (as a oneof) labeled with tag “t". For example, 
number$make_real_num(1.37) 

creates a oneof object with tag “real_num” (assuming “number” has been equated to the “number 
container” type specification above; see Section 8.3). . 

The equal (=) operation tests if two oneofs have the same tag, and if so, tests if the two value 
components are the same, using the equal operation of the value type. Similar tests if two oneofs 
have the same tag, and if so, tests if the two value components are similar, using the similar 


operation of the value type. 
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To determine the tag and value of a oneof object, one normally uses the tagcase statement, 


discussed in Section 116. 
7.13 Variant Types 


A variant is a mutable oneof. A variant type specification has the form 

variant [ field_spec , ... J 
where (as for records) 

field_spec ::= name,... ; type_spec 
The state of a variant is a pair consisting of a label called the fag and an object called the value. 
For each tag “t" of a variant type, there is a make_t operation which takes an object of the type 
associated with the tag, and returns the object (as a variant) labeled with tag “t". In addition, there 
is a change_t operation, which takes an existing variant and an object of the type associated with 
"t", and changes the state of the variant to be the pair consisting of the tag “t" and the given 
ob ject. 

Every newly created variant has an identity that is distinct from all other variants; two 
variants can have the same state without being the same variant object. The identity of variants 
can be distinguished using the equal (=) operation. The similar! operation tests if two variants” 
have the same tag, and if so, tests if the two value components are equal, using the equal operation 
of the value type. Similar tests if two variants have the same tag, and if so, tests if the two value 
components are similar, using the similar operation of the value type. 

To determine the tag and value of a variant object, one normally uses the tagcase statement, 


as discussed in Section 11.6. 
7.14 Procedure and Iterator Types 


Procedures and iterators are objects created by the CLU system (see Section 3.1). The type 
specification for a procedure or iterator contains most of the information stated in a procedure or 
iterator heading; a procedure type specification has the form 

proctype ( [ type_spec , ... ) [ returns ] [ signals | 
and an iterator type specification has the form 
itertype ( [ type_spec , ... ] ) [ yields ] [ signals | 


where 
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returns ss returns ( type_spec,... ) 

yields z= ylelds ( type_spec ,... ) 

Signals ::= signals ( exception, ... ) 

exception ::= name [ ( type_spec : ee) ] 
The first list of type specifications describes the number, types, and order of arguments. The 
returns or ylelds clause gives the number, types, and order of the objects to be returned or 
yielded. The signals clause lists the exceptions raised by the procedure or iterator; for each 
exception name, the number, types, and order of the objects to be returned is also given. All names 
used in a signals clause must be unique, and cannot be failure, which has a standard meaning in 
CLU (see Section 12.1). The ordering of exceptions is not important. For example, both of the 
following type specifications name the procedure type for string$substr: 


proctype (string, int, int returns (string) signals (bounds, negative_size) 
Proctype (string, int, int) returns (string) signals (negative_size, bounds) 


String$chars has the following iterator type: 
itertype (string) yields (char) 
Procedure and iterator types have an equal (=) operation. Invocation is not an operation, but a 


primitive action of CLU semantics (see Section 9.3). 
7.15 Other Type Specifications 


The type specification for a user-defined type has the form 
idn [ { constant ,... J ] 
where each constant must be computable at compile-time (see Section 8.3). The identifier must be 
bound to a data abstraction (see Section 4). If the referenced abstraction is parameterized, 
constants of the appropriate types and number must be supplied. The order of parameters always 
matters in user-defined types. 

There are three special type specifications that are used when implementing new abstractions: 
rep, cvt, and type. These forms are discussed in Sections 13.3 and 13.4. Within an 
implementation of an abstraction, formal parameters declared with type can be used as type 
specifications. | 

In addition, identifiers which have been equated to type specifications can also be used as type 


specifications. Equates are discussed in Section 8.3. 


34 Scopes, Declarations, and Equates §8 


8. Scopes, Declarations, and Equates 


We now describe how to introduce and use constants and variables, and the scope of constant 
and variable names. Scoping units are described first, followed by a discussion of variables, and 


finally constants. 
8.1 Scoping Units 


Scoping units follow the nesting structure of statements. Generally, a scoping unit is a body 
and an associated “heading”. The scoping units are (refer also to Appendix 1): 
1. From the start of a module to its end. 
2. From a cluster, proc, or iter to the matching end. 
3. From a for, do, or begin to the matching end. 
4 


. From a then or else in an If statement to the end of the corresponding 
body. 


5. From a tag or others in a tagcase statement to the end of the 
corresponding body. 


6. From a when or others in an except statement to the end of the 
corresponding body. 


7. From the start of a type_set to its end. 
The last case above, the scope in a type_set, is a special case that will be discussed in Section 13.4. 
Whatever we say about scopes in the remainder of this section refers only to cases 1 through 6. 

The structure of scoping units is such that if one scoping unit overlaps another scoping unit 
(textually), then one is fully contained in the other. The contained scope is called a nested scope, 
and the containing scope is called a surrounding scope. 

New constant and variable names may be introduced in a scoping unit. Names for constants 
are introduced by equates, which are syntactically restricted to appear grouped together at or near 
the beginning of scoping units. For example, equates may appear at the beginning of a body, but 
not after any statements in the body. 

In contrast, declarations, which introduce new variables, are allowed wherever statements are 
allowed, and hence may appear throughout a scoping unit. Equates and declarations are discussed 


in more detail in the following two sections. 
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In the syntax there are two distinct nonterminals for identifiers: idn and name. Any identifier 
introduced by an equate or declaration is an idn, as is the name of the module being defined, and 
any operations it has. An idn names a specific type or object. The other kind of identifier is a 
name. A name is used to refer to a subpiece of something, and is always used in context; for 
example, names are used as record selectors. The scope rules apply only to idns. 

The scope rules are very simple: 

1. An idn may not be redefined in its scope. 


2. Any idn that is used as an external reference in a module may not be 
used for any other purpose in that module. 


Unlike other “block-structured” languages, CLU prohibits the redefinition of an identifier in a 
nested scope. An identifier used as an external reference names a module or constant; the reference 


is resolved using the compilation environment (see Section 4). 
8.2 Variables 


Objects are the fundamental “things” in the CLU universe; variables are a mechanism for 
denoting (i.e, naming) objects. This underlying model is discussed in detail in Section 3. A 
variable has two properties: its type, and the ob ject that it currently denotes (if any). A variable is 
said to be uninitialized if it does not denote any ob ject. | 

There are only three things that can be done with variables: 


1. New variables can be introduced. Declarations perform this function, 
and are described below. 


2. An object may be assigned to a variable. After an assignment the 
variable denotes the object assigned. Assignment is discussed in 
Section 9.2. 


3. A variable may be used as an expression. The value of such an 
expression (ie., the result of evaluating it) is the object that the 
variable denotes at the time the expression is evaluated. Expressions 
and their evaluation are described in Section 10. 


8.2.1 Declarations 


Declarations introduce new variables. The scope of a variable is from its declaration to the 
end of the smallest scoping unit containing its declaration; hence, variables must be declared before 


use. 


36 Declarations §8.2.1 


There are two sorts of declarations: those with initialization, and those without. Simple 
declarations (those without initialization) take the form 
decl ::= idn,... : type_spec ; 
A simple declaration introduces a list of variables, all having the type given by the type_spec. This 
type determines the types of ob jects that can be assigned to the variable. Some examples of simple 


declarations are: 


i: int % declare i to be an integer variable 

i, j. k: char % declare i, j, and k to be character variables 

x, y: complex % declare x and y to be of type complex 

z: any % declare z to be of type any; thus, z may denote any ob ject 


The variables introduced in a simple declaration initially denote no objects, i.e. they are 
uninitialized. Attempts to use uninitialized variables (if not detected at compile-time) cause the 
run-time exception 

failure("uninitialized variable”) 


(Exceptions are discussed in Section 12.) 
8.2.2 Declarations with Initialization 


A declaration with initialization combines declarations and assignments into a single statement. . 
A declaration with initialization is entirely equivalent to one or more simple declarations followed 
by an assignment statement. The two forms of declaration with initialization are: 
idn : type_spec := expression 
and 
decl;, ..., decl,, := invocation 
These are equivalent to (respectively): 


idn : type_spec 
idn := expression 


and 
decl, ... decl,  % declaring idn, ... idny, 
idny. ses idn,, := invocation 
In the second form, the order of the idns in the assignment statement is the same as in the original 


declaration with initialization. (The invocation must return m ob jects; see Section 9.2.2.) 


§8.2.2 Declarations with Initialization 37 


Some examples of declarations with initialization are: 
astr: arrayl string] := arrayl string]$create(1) 
% declare astr to be an array variable and initialize it to an empty array 


first, last: string, balance: int := acct$query(acct_no) 
% declare first and last to be string variables, balance an integer variable, 
% and initialize them to the results of a bank account query 


The above two statements are equivalent to the following sequences of statements: 
astr: arrayl string) 


astr := arraylstring)$create(1) 


first, last: string 
balance: int 
first, last, balance := acct$query(acct_no) 


8.3 Equates and Constants 


An equate allows a single identifier to be used as an abbreviation for a constant that may have 
a lengthy textual representation. We use the term constant in a very narrow sense here: constants, 
in addition to being immutable, must be computable at compile-time. Constants are either types 
(built-in or user-defined), or objects that are the results of evaluating constant expressions. 
(Constant expressions are defined below.) 

The syntax of equates is: 

equate ::= idn = constant 
| idn = type_set 
constant ::= type_spec 
| expression 
This section describes only the first form of equate; discussion of type_sets is deferred to 
Section 13.4. 

An equated identifier may be used as an expression. The value of such an expression is the 
constant to which the identifier is equated. An equated identifier may not be used as the target of 
an assignment. 

The scope of an equated identifier is the smallest scoping unit surrounding the equate defining 
it; here we mean the entire scoping unit, not just the portion after the equate. All the equates in a 
Scoping unit must appear near the beginning of the scoping unit. The exact placement of equates 


depends on the containing syntactic construct; usually equates appear at the beginnings of bodies. 
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Equates may be in any order within the group. Thus, forward references among equates in 
the same scoping unit are allowed, but cyclic dependencies are illegal. For example, 


xy 


yrz 
z=3 


is a legal sequence of equates, but 


X=y 
y=2 
Z=X 


is not. Since equates introduce idns, the scoping restrictions on idns apply (i.e, the idns may not be 


defined more than once). 
8.3.1 Abbreviations for Types 


Identifiers may be equated to type specifications, thus giving abbreviations for type names. 


For example: 


at = arrayl int) 

ot = oneofithere: rt, none: null) 

rt = recordla: foo, b: bar) 

pt = proctype (int, int) returns (int) signals (overflow) | 
it = itertype (int, int, ind yields (ind signals (bounds) 
istack = stacklint] 

mt = mark_table 


Notice that since equates may not have cyclic dependencies, directly recursive type specifications 
cannot be written. However, this does not prevent the definition of recursive types: clusters allow 


them to be written (see Section 13). 
8.3.2 Constant Expressions 


Here we define the subset of objects that equated identifiers may denote, by stating which 
expressions are constant expressions. (Expressions are discussed in detail in Section 10.) A constant 
- expression is an expression that can be evaluated at compile-time to produce an immutable ob ject 
of a built-in type. Specifically this includes: 

1. Literals. © 


2. Identifiers equated to constants. 
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3. Procedure and iterator names (see Section 10.3), including force{¢) for 
any type f. 


4. Invocations of procedure operations of the built-in constant types, 
provided that all operands and all results are constant expressions. 
However, we explicitly forbid the use of formal parameters as operands 
to invocations in constant expressions, since the values of formal 
parameters are not known at compile-time. 


5. Formal parameters (see Section 13.4). 
For completeness, the list of the built-in constant types is: null, int, real, bool, char, string, 
sequence types, oneof types, structure types, procedure types, and iterator types. 
Some examples of equates involving expressions are: 


hash_modulus = 29 

pi = 3.14159265 

win = true 

control_c = \003" 

prompt string = “Input: ” 

nl = string$c2s(‘\n’) 

prompt = nl Il prompt_string 
prompt_ten = string$size(prompt) 
quarter = pi / 2.0 

ftb = int$from_to_by 

ot = oneofilcell: cell, none: null] 
cell = record(first, second: int) 
nilptr = ot$make_none(nil 


Note that the following equate is illegal because it uses a record constructor, which is not a constant 
expression: 
cell_1_2 = ot$make_cell{cell${first: 1, second: 2}) 
Any invocation in a constant expression must terminate normally; a program is illegal if 
evaluation of any constant expression would signal an exception. (Exceptions are discussed in 


Section 12.) I"legal programs will not be executed. 


9. Assignment and Invocation 


Two fundamental actions of CLU are assignment of computed objects to variables, and 
invocation of procedures (and iterators) to compute objects. Other actions are composed from these 
two by using various control flow mechanisms. Since the correctness of assignments and 


invocations depends on a type-checking rule, we describe that rule first, then assignment, and 
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finally invocation. 
9.1 Type Inclusion 


CLU is designed to allow compile-time type-checking. The type of each variable is known by 
the compiler. Furthermore, the type of objects that could result from the evaluation of any 
expression (invocation) is known at compile-time. Hence, every assignment can be checked at 
compile-time to make sure that the variable is only assigned objects of its declared type. The rule 
is that an assignment v := E is legal only if the set of objects defined by the type of E (loosely, the 
set of afl objects that could possibly result from evaluating the expression) is included in the set of 
all ob jects that could be denoted by v. 

Instead of speaking of the set of objects defined by a type, we generally speak of the type and 
say that the type of the expression must be included in the type of the variable. If it were not for 
the type any, the inclusion rule would be an equality rule. This leads to a simple interpretation of 
the type inclusion rule: 


The type of a variable being assigned an expression must be either the type of the 
expression, or any. ; 


9.2 Assignment 


Assignment is the means of causing a variable to denote an object. Some assignments are 
implicit, i.e, performed as part of the execution of various mechanisms of the language (most 
notably procedure invocation, iterator invocation, exception handling, and the tagcase statement). 
All assignments, whether implicit or explicit, are subject to the type inclusion rule. The remainder 
of this section discusses explicit assignments. 

The assignment symbol *:=" is used in two other syntactic forms that are not true assignments, 
but rather abbreviations for certain invocations. These forms are used for updating collections 


such as records and arrays (see Section 11.2). 
9.2.1 Simple Assignment 


The simplest form of assignment is: 
idn := expression 


In this case the expression is evaluated, and the resulting object is assigned to the variable. The 
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expression must return a single object (whose type must be included in that of the variable). 


Examples of simple assignments are: 


x := 1 % x's type must include int, i.e., it must be Int or any 
y := String$substr(s, 5, n) % y's type must include string 

a := arraylint]$new() % a's type must include arraylint) 

p := arraylint)$create(3) % p's type must include arraylint) 

z := (foo = bar) % 2's type must include bool 


It is also possible to declare a variable and assign to it in a single statement; this is called a 


declaration with initialization, and was discussed in Section 8.2.2. 
9.2.2 Multiple Assignment 


There are two forms of assignment that assign to more than one variable at once: 
idn, we c= expression , ... | 
and 
idn , ... := invocation 

The first form of multiple assignment is a generalization of the simple assignment. The first 
variable is assigned the first expression, the second variable the second expression, and so on. The 
expressions are all evaluated (from left to right) before any assignments are performed. The 
number of variables in the list must equal the number of expressions, no variable may occur more 
than once, and the type of each variable must include the type of the corresponding expression. 


This form of multiple assignment allows easy permutation of the objects denoted by several 


variables: 
X,yi=y,X 
i, j,k v= jv kei 


and similar simultaneous assignments of variables that would otherwise require temporary 
variables: 


a, b := (a + b), (a - b) 
quotient, remainder := (u / v), (u // v) 


There is no form of this statement with declarations. 

The second form of multiple assignment allows one to retain the objects resulting from an 
invocation returning two or more objects. The first variable is assigned the first object, the second 
variable the second object, and so on. The order of the objects is the same as in the return 
statement of the invoked routine. The number of variables must equal the number of ob jects 


returned, no variable may occur more than once, and the type of each variable must include the 
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corresponding return type of the invoked procedure. Note that the right-hand side is syntactically 
restricted to simple invocations (see Section 10.4); sugared invocations (see Sections 10.5, 10.7) are not 
allowed. 

Two examples of this farm of assignment are: 


first, last, balance := acct$querylacct_no) 
X, y, Z = vector$components(v) 


9.3 Invocation 


Invocation is the other fundamental action of CLU. In this section we discuss procedure 
invocation; iterator invocation is discussed in Section 115.2. However, up to and including passing 
of arguments, the two are the same. 

- Invocations take the form: 
primary ( [ expression , ... p 
A primary is a slightly restricted form of expression, which includes variables and routine names, 
among other things. (See the next section.) 

The sequence of activities in performing an invocation are as follows: 

1. The primary is evaluated. It must evaluate to a procedure or iterator. 
2. The expressions are evaluated, from left to right. 


3. New variables are introduced corresponding to the formal arguments 
of the routine being invoked (i.e, a new environment is created for the 
invoked routine to execute in). 


4. The objects resulting from evaluating the expressions (the actual 
arguments) are assigned to the corresponding new variables (the formal 
arguments). The first formal is assigned the first actual, the second 

_ formal the second actual, and so on. The type of each expression must 
be included in the type of the corresponding formal argument. 


5. Control is transferred to the routine at the start of its body. 
An invocation is considered egal in exactly those situations where all the (implicit) assignments 
invotved in its execution are legal. 

It is permissible for a routine to assign an object to a formal argument variable; the effect is 
just as if that object were assigned to any other variable. From the point of view of the invoked 
routine, the only difference between its formal argument variables and its other local variables is 
that the formals are initialized by its caller. 
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Procedures can terminate in two ways: they can terminate normally, returning zero or more 
ob jects, or they can terminate exceptionally, signalling an exceptional condition. When a procedure 
terminates normally, the result ob jects become available to the caller, and will (usually) be assigned 
to variables or passed as arguments to other. routines. When a procedure terminates exceptionally, 
the flow of control will not go to the point of return of the invocation, but rather will go elsewhere 
as described in Section 12. 


Some examples of invocations are: 


pO % invoking a procedure taking no arguments 
arraylint]$create(-D % invoking an operation of a type 
routine_tablel index (input) % invoking a procedure fetched from an array 


10. Expressions 


An expression evaluates to an object in the CLU universe. This object is said to be the result 
or value of the expression. Expressions are used to name the object to which they evaluate. The 
simplest forms of expressions are literals, variables, and routine names. These forms directly name 
their result object. More complex expressions are generally built up out of nested procedure 
invocations. The result of such an expression is the value returned by the outermost invocation. 

Like many other languages, CLU has prefix and infix operators for the common arithmetic 
and comparison operations, and uses the familiar syntax for array indexing and record component 
selection (e.g., ali] and 1.s). However, in CLU these notations are considered to be abbreviations 
for procedure calls. This allows built-in types and user-defined types to be treated as uniformly as 
possible, and also allows the programmer to use familiar notation when appropriate. 

In addition to invocation, four other forms are used to build complex expressions out of 
simpler ones. These are the conditional operators cand and cor (see Section 10.8), and the type 
conversion operations up and down (see Section 10.10). 

There is a syntactically restricted form of expression called a primary. A primary is any 
expression that does not have a prefix or infix operator, or parentheses, at the top level. In certain 
places, the syntax requires a primary rather than a general expression. This has been done to 


increase the readability of the resulting programs. 
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As a general rule, procedures with side effects should not be used in expressions, and programs 
should not depend on the order in which expressions are evaluated. However, to avoid surprises, 
the subexpressions of any expression are evaluated from left to right. 


The various forms of expressions are explained below. 
10.1 Literals 


Integer, real, character, string, boolean and null literals are expressions. The syntax for literals 
is given in Sections 7.1 to 7.6. The type of a literal expression is the type of the object named by 
the literal. For example, true is of type bool, “abc” is of type string, etc. 


10.2 Variables 


Variables are identifiers that name objects of a given type. The type of a variable is the type 
given in the declaration of that variable, and determines which objects may be named by the 


variable. 
10.3 Procedure and Iterator Names 


Procedures and iterators may be defined either as separate modules, or within a cluster. Those 
defined as separate modules are named by expressions of the form: 
idn [ [ constant, ... ] ] 
The optional constants are the parameters of the procedure or iterator abstraction. (Constants were 
discussed in Section 8.3.) 
When a procedure or iterator is defined as an operation of a type, that type must be part of 
the name of the routine. The form for naming an operation of a type is: | 
type_spec $ name [ { constant, ... ] ] 
The type of a procedure or iterator name is just the type of the named routine. Some 
examples of procedure and iterator names are: 


primes 

sortlint] 

int$add 

arrayl bool]$elements 
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10.4 Procedure Invocations 


Procedure invocations have the form 
primary ( [ expression , ... ] ) 
The primary is evaluated to obtain a procedure object, and then the expressions are evaluated left- 
to-right to obtain the argument objects. The procedure is invoked with these arguments, and the 
ob ject returned is the result of the entire expression. For more discussion see Section 9.3. 
The following expressions are invocations: 


p(x) 
int$add(a, b) 
within{3.2)(7.1, .003e7) 


Any procedure invocation P(E), ... E,,) must satisfy two constraints: the type of P must be of 
the form | 
proctype (Ty, .. T,,) returns (R) signals (...) 
and the type of each expression E, must be included in the corresponding type Tj. The type of the 
entire invocation expression is given by R. 


Procedures can also be invoked as statements (see Section 11.1). 
10.5 Selection Operations 


Arrays, sequences, records, and structures are collections of objects. Selection operations 
provide access to the individual elements or components of the collection. Simple notations are 
provided for invoking the fetch and store operations of array types, the fetch operation of sequence 
types, the get and set operations of record types, and the get operations of structure types. In 
addition, these “syntactic sugarings” for selection operations may be used for user-defined types 


with the appropriate properties. 
10.6.1 Element Selection 


An element selection expression has the form: 
primary [ expression ] 
This form is just syntactic sugar for an invocation of a fetch operation, and is completely 
equivalent to: 


T$fetch(primary, expression) 
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where T is the type of primary. For example, if a is an array of integers, then 
a{27} 

is completely equivalent to the invocation 
arraylint]$fetch(a, 27) 

When primary is an arraylS] or sequencelS] for some type S, expression must be an int, and 
the result has type S. However, the element selection expression is not restricted to arrays and 
sequences. The expression is legal whenever the corresponding invocation is legal. In other words, 
T (the type of primary) must provide a procedure operation named fetch, which takes two 
arguments whose types include the types of primary and expression, and which returns a single 
result. 

The use of fetch for user-defined types should be restricted to types with array-like behavior. 
Ob jects of such types will contain (along with other information) a collection of objects, where the 
collection can be indexed in some way. For example, it might make sense for an 
associative_memory type to provide a fetch operation to access the value associated with a key. 
Fetch operations are intended for use in expressions; thus they should never have side-effects. 


Array-like types may also provide a store operation (see Section 11.2.1). 
10.5.2 Component Selection 


The component selection expression has the form: 
primary . name 
This form is just syntactic sugar for an invocation of a get_name operation, and is completely 
equivalent to: 
T$get_name(primary) 
where T is the type of primary. For example, if x has type record{first: Int, second: reafl, then 
x first 
is completely equivalent to 
record{first: int, second: reall$get_first(x) 

When T is a record or structure type, then T must have a selector called name, and the type of 
the result will be the type of the component named by that selector. However, the component 
selection expression is not restricted to records and structures. The statement is legal whenever the 
corresponding invocation is legal. In other words, T (the type of primary) must provide a 


procedure operation named get_name, which takes one argument whose type includes the type of 
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primary, and which returns a single result. 

The use of get operations for user-defined types should be restricted to types with record-like 
behavior. Objects of such types will contain (along with other information) one or more named 
ob jects. For example, it might make sense for a file type to provide a get_author operation, which 
returns the name of a file’s creator. Get operations are intended for use in expressions; thus they 
should never have side-effects. 


Types with named components may also provide set operations (see Section 11.2.2). 
10.6 Constructors 


Constructors are expressions that enable users to create and initialize arrays, sequences, records, 


and structures. Constructors are not provided for user-defined types. 
10.6.1 Array Constructors 


An array constructor has the form: 
type_spec $ [ [ expression: ] [ expression , ... ] ) 
The type specification must name an array type: array{T). This is the type of the constructed 
array. The expression preceding the *:” must evaluate to an integer, and becomes the low bound of 
the constructed array. If this expression is omitted, the low bound is 1. The expressions following 
the “:" are evaluated to obtain the elements of the array. They correspond (left to right) to the 
indexes /ow_bound, low_bound+1, low_bound+2, ... For an array of type array(T], the type of each 
element expression in the constructor must be included in T. 
For example, the expression 
array(bool] $ (79: true, false] 
constructs a new boolean array with two elements: true (at index 79), and false (at index 80). The 
expression 
arraylai) $ (ai${), ai$(]] 
(where ai is equated to array(int]) creates two distinct integer arrays, both empty, and creates a 
third array to hold them. The low bound of each array is 1. 
An array constructor is computationally equivalent to an array create operation, followed by a 
number of array add operations. However, such a sequence of operations cannot be written as an 


expression. 
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10.6.2 Sequence Constructors 


A sequence constructor has the form: 
type_spec $ [ [ expression , ... }} 

The type specification must name a sequence type: sequencelT]. This is the type of the 
_ constructed sequence. The expressions are evaluated to obtain the elements of the sequence. They 
correspond (left to right) to the indexes 1, 2, 3, ... For a sequence of type sequencel T], the type of 
each element expression in the constructor must be included in T. 

A sequence constructor is computationally equivalent to a sequence new operation, followed by a 
number of sequence addh operations. 


10.6.3 Record Constructors 


‘A record constructor has the form: 
type_spec $ { field ,...} 
where 
field ::= name... : expression 
Whenever a field has more than one name, it is equivalent to a sequence of fields, one for each 
name. Thus, the following two constructors are equivalent: . 


R = record, a: int, b: int, c: int] 
R$la, b: 7, c: 9} 
RS${a: 7, b: 7, c: 9} 


In a record constructor, the type specification must name a _ record § type: 
record [S):T), .... 5,:T,). This will be the type of the constructed record. The component names 
in the field list must be exactly the names S), ....S,, although these names may appear in any 
order. The expressions are evaluated left to right, and there is one evaluation per component 
name even if several component names are grouped with the same expression. The type of the 
expression for component S; must be included in T;. The results of these evaluations form the 
components of a newly constructed record. This record is the value of the entire constructor 
expression. 

As an example, consider the following record constructor: 


AS = arrayl string) 
RT = record list, list2: AS, item: int] 
RTStitem: 2, listl, list2: AS${"Susan”, “George”, “Jan"]} 
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This produces a record that contains an integer and two distinct (but similarl) arrays. The arrays 
are distinct because the array constructor expression is evaluated twice, once for list! and once for 
list2. 

A record constructor is computationally equivalent to a record create operation (see 


Appendix II), but that operation is not available to the user. 
10.6.4 Structure Constructors 


A structure constructor has the form: 
type_spec $ { field ,... } 
where (as for records) 
_ field s:= name, ... : expression 
Whenever a field has more than one name, it is equivalent to a sequence of fields, one for each 
name. 

In a structure constructor, the type specification must mame a_ structure type: 
struct [S;:T}, ....S,:T,]. This will be the type of the constructed structure. The component 
names in the field list must be exactly the names S). a Sp» although these names may appear in 
any order. The expressions are evaluated left to right, and there is one evaluation per component 
name even if several component names are grouped with the same expression. The type of the 
‘expression for component S, must be included in T;. The results of these evaluations form the 
components of a newly constructed structure. This structure is the value of the entire constructor 
expression. 

A structure constructor is computationally equivalent to a structure create operation (see 


Appendix II), but that operation is not available to the user. 
10.7 Prefix and Infix Operators 


CLU allows infix and prefix notation to be used as a shorthand for the following operations. 
The table shows the shorthand form and the equivalent expanded form for each operation. For 


each operation, the type T is the type of the first operand. 


Shorthand form 


expry ** expro 
expr, // expro 
expr, / expro 
expr) * expro 
expr, fl expro 
expr) + expro 
expr) - expro 
eXpry < eXpro 
CXPl, <= EXPlo 
expry = expro 
expr, >= expro 
expr) > expro 
expr) ~< expro 
expr) ~<= expro 
eXpry v= expr 
eXpry ~>= eXpro 
expr, ~> explo 
expr, & expro 
expr, | expro 

- expr 

~ expr 


Prefix and Infix Operators 


Expansion 
TSpowerlex pr), expro) 
T$mod(expry, expr) 
TSdivlexpr), expro) 
T$mulexpr), expro) 
T$concatlexpr), expr) 
T$add(expry, expr) 
T$sublexpr), expro) 
TSitlexpry, expro) 
T$lelexpr), expro) 
TS$equaKexpr), expro) 
T$getexpry, expro) 
TSgtlexpr,, expr) 

~ (expry < expr) 

~ (expr) <= expro) 

~ (expr) = expro) 

~ (expr) >= expto) 

~ (expry > expro) 
TSand(expry, expro) 
TSorlexpr), expr) 
T$minus(expr) 
T$notlexpr) 


§10.7 


Operator notation is used most heavily for the buit-in types, but may be used for 


user-defined types as well. When these operations are provided for user-defined types, they 
should always be side-effect free, and they should mean roughly the same thing as they do for the 
built-in types. For example, the comparison operations should only be used for types that have a 
natural partial or total order. Usually, the comparison operations (lt, le, equal, ge, gt) will be of type 
proctype (T, T) returns (booD 
the other binary operations (e.g., add, sub) will be of type 
proctype (T, T) returns (T) signais (..) 
and the unary operations will be of type 
proctype (T) returns (T) signals (...) 
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10.8 Cand and Cor 


Two additional binary operators are provided. These are the conditional and operator, cand, 
and the conditional or operator, cor. 
expression, cand expressiono 
is the boolean and of expression, and expressiono. However, if expression, is false, expressions is 
never evaluated. 
expression) cor expressiony 
is the boolean or of expression, and expressiono, but expressiong is not evaluated unless 
expression, is false. For both cand and cor, expression, and expressiony must have type bool. 
Conditional expressions can be used to avoid run-time errors. For example, the following 
boolean expressions can be used without fear of “bounds” or “zero_divide” errors: 


(low_bound <= i) cand (i <= high_bound) cand (ALi) ~= 0) 
(n = 0) cor (1000//n = 0) 


Because of the conditional expression evaluation involved, uses of cand and cor are not 


equivalent to any procedure invocation. 
10.9 Precedence 


When an expression is not fully parenthesized, the proper nesting of subexpressions might be 
ambiguous. The following precedence rules are used to resolve such ambiguity. The precedence 
of each infix operator is given in the table below. Higher precedence operations are performed 
first. Prefix operators always have precedence over infix operators. 


The precedence for infix operators is as follows: 


Precedence Operators 


5 t? 

4 e / // 

3 +  - ll 

2 < <= = >= > 
we w= wm we “~> 

i & cand 
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The order of evaluation for operators of the same precedence is left to right, except for ¢s, 
which is right to left. 


The following examples illustrate the precedence rules. 


Expression , Equivalent Form 
a+b//c , a+(b//a 
atb-c (a+b)-c 
a+berecesd a+ (b ss (c ss d)) 
a=blced (a=b) l(c =d) 
-atb (-a) ¢b 


10.10 Up and Down 


There are no implicit type conversions in CLU. Two forms of expression exist for explicit 
conversions. These are: 


up ( expression ) 
down ( expression ) 


Up and down may be used only within the body of a cluster operation. Up changes the type 
of the expression from the representation type of the cluster to the abstract type. Down converts 
the type of the expression from the abstract type to the representation type. These conversions will 


_ be explained further in Section 13.3. 
10.11 Force 


CLU has a single built-in procedure generator called force. Force takes one type parameter, 
and is written 
force [ type_spec ] 
The procedure force{T] has type 
proctype (any) returns (T) signals (wrong_type) 
If force(T] is applied to an object that is included in type T, then it returns that object. If 
forcelT] is applied to an object that is not in type T, then it signals “wrong_type™ (see Section 12). 
Force is a necessary companion to the type any. The type any allows programs to pass 
around objects of arbitrary type. However, to do anything substantive with an object, one must 


use the primitive operations of that object's type. This raises a conflict with compile-time 
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type-checking, since an operation can be applied only when the arguments are known to be of the 
correct types. This conflict is resolved by using force. ForcelT) allows a program to check, at 
run-time, that a particular object is actually of type T. If this check succeeds, then the ob ject can 
be used in all the ways appropriate for ob jects of type T. 

For example, the procedure force[T] allows us to legally write the following code: 


xX: any := 3 
y: int := forcelinti(x) 


while the following is iltegal: 


x: any := 3 
y: int := x 


because the type of 9 (Int) does not include the type of the expression x (any). 


11. Statements 


In this section, we describe most of the statements of CLU. We omit discussion of the signal, 
exit, and except statements, which are used for signalling and handling exceptions, as described 
in Section 12. . 

CLU is a statement-oriented language, i.e., statements are executed for their side-effects and 
do not return any values. Most statements are control statements that permit the programmer to 
define how control flows through the program. The real work is done by the simple statements: 
assignment and invocation. Assignment has already been discussed in Section 9; the invocation 
statement is discussed in Section 11.1 below. Two special statements that look like assignments but 
are really invocations are discussed in Section 11.2. 

The syntax of CLU is defined to permit a control statement to control a group of equates, 
declarations, and statements rather than just a single statement. Such a group is called a body, and 
has the form 

body ::= { equate } 
{ statement } % statements include declarations 
Scope rules for bodies were discussed in Section 8.1. No special terminator is needed to signify the 
end of a body; reserved words used in the various compound statements serve to delimit the bodies. 
Occasionally it is necessary to explicitly indicate that a group of statements should be treated like a 


single statement; this is done by the block statement, discussed in Section 11.3. 
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The conditional statement is discussed in Section 11.4. Loop statements are discussed in 
Section 11.5, as are some special statements that control termination of a single iteration or a single 
loop. The tagcase statement is discussed in Section 11.6. Finally, the return statement is 


discussed in Section 11.7, and the yleld statement in Section 11.8. 
11.1 Procedure Invocation 


An invocation statement invokes a procedure. Its form is the same as an invocation 
expression: ' 
primary ( [ expression , ... ) 
The primary must evaluate to a procedure ob ject, and the type of each expression must be included 
in the type of the corresponding formal argument for that procedure. The procedure may or may 
not return results; if it does return results, they are discarded. 
For example, the statement 
array(int)$remh(a) 
will remove the top element of a (assuming a is an arraylint)). Remh also returns the top element, 
but it is discarded in this case. 


11.2 Update Statements 


Two special statements are provided for updating components of records and arrays. In 
addition they may be used with user-defined types with the appropriate properties. These 


Statements resemble assignments syntactically, but are really invocations. 
11.2.1 Element Update 


The element update statement has the form 
primary [ expression, J := expressiono 
This form is merely syntactic sugar for an invocation of a store operation, and is completely 
equivalent to the invocation statement 
T$store(primary, expression), expressiono) 
where T is the type of primary. For example, if a is an array of integers, 
al27] := 3 


is completely equivalent to the invocation statement 
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arraylint]$store(a, 27, 3) 

The element update statement is not restricted to arrays. The statement is legal if the 
corresponding. invocation statement is legal. In other words, T (the type of primary) must provide 
a procedure operation named store, which: takes three arguments whose types include those of 
primary, expression >, and expression», respectively. In case primary is an array(S) for some type S, 
expression, must be an integer, and expression, must be included in S. 

We recommend that the use of store for user-defined types be restricted to types with 
array-like behavior, i.e., types whose objects contain mutable collections of indexable elements. For 
example, it might make sense for an associative memory type to provide a store operation for 
changing the value associated with a key. Such types may also provide a fetch operation (see 


Section 10.5.1). 
11.2.2 Component Update 


The component update statement has the form 
primary . name := expression 
This form is merely syntactic sugar for an invocation of a set_name operation, and is completely 
equivalent to the invocation statement . 
T$set_name(primary, expression) 
where T is the type of primary. For example, if x has type record{first: int, second: real), then 
x.first := 6 
is completely equivalent to 
record[first: int, second: reatl$set_first(x, 6) 

The component update statement is not restricted to records. The statement is legal if the 
corresponding invocation statement is legal. In other words, T (the type of primary) must provide 
a procedure operation called set_name, which takes two arguments whose types include the types of 
primary and expression, respectively. When T is a record type, then T must have a selector called 
name, and the type of expression must be included in the type of the component named by that 
selector. 

We recommend that sef operations be provided for user-defined types only if record-like 
behavior is desired, i.e., it is meaningful to permit some parts of the abstract object to be modified 
by selector name. In general, set operations should not perform any substantial computation, except 


possibly checking that the arguments satisfy certain constraints. For example, in a bank account 
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type, there might be a set_min_balance operation to set what the minimum balance in the account 
must be. However, deposit and withdraw operations make more sense than a set_balance operation, 
even though the sef_balance operation could compute the amount deposited or withdrawn and 
enforce semantic constraints. 

In our experience, types with set operations occur less frequently than types with get operations 
(see Section 10.5.2). 


11.8 Block Statement 


The block statement permits a sequence of statements to be grouped together into a single 
Statement. Its form is 
begin body end 
Since the syntax already permits bodies inside control statements, the main use of the block 


statement is to group statements together for use with the except statement; see Section 12. 
11.4 Conditional Statement 


The form of the conditional statement is 
if expression then body 
{ elseif expression then body } 


[ i body ] 


The expressions must be of type bool. They are evaluated successively until one is found to be 
true. The body corresponding to the first true expression is executed, and the execution of the if 
statement then terminates. If none of the expressions is true, then the body in the else clause is 
executed (if the else clause exists). The elseif form provides a convenient way to write a 


multi-way branch. 
11.5 Loop Statements 


There are two forms of loop statements: the while statement and the for statement. Also 
provided are a continue statement, to terminate the current cycle of a loop, and a break statement, 


to terminate the innermost loop. These are discussed below. 
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11.5.1 While Statement 


The while statement has the form: 
while expression do body end 
Its effect is to repeatedly execute the body as long as the expression remains true. The expression 
must be of type bool. If the value of the expression is true, the body is executed, and then the 
entire while statement is executed again. When the expression evaluates to false, execution of the 


while statement terminates. 
11.6.2 For Statement 


The only way an iterator (see Section 13.2) can be invoked is by use of a for statement. The 
iterator produces a sequence of items (where an item is a group of zero or more ob jects) one item at 
a time; the body of the for statement is executed for each item in the sequence. 

The for statement has the form: 

for [ idn , ... J in invocation do body end 
or 

for [ decl,... ] in invocation do body end 
The invocation must be an iterator invocation. The idn form uses previously declared variables to 
serve as the loop variables, while the dec! form introduces new variables, local to the for statement, 
for this purpose. In either case, the type of each variable must include the corresponding yield 
type of the invoked iterator. 

Execution of the for statement proceeds as follows. First the iterator is invoked, and it either 
yields an item or terminates. If the iterator yields an item, its execution is temporarily suspended, 
the objects in the item are assigned to the loop variables, the body of the for statement is executed, 
and then execution of the iterator is resumed (from the point of suspension). Whenever the 
iterator terminates, the entire for statement terminates. 

An example of a for statement is 

a: arraylint) 
sum: int := 0 
for x: int in arraylint}$elements(a) do 


sum := sum + X 
end 


which will compute the sum of all the integers in an array of integers. This example makes use of 
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the elements iterator on arrays, which yields the elements of the array one by one. 
11.6.3 Continue Statement 


The continue statement has the form 
continue 
Its effect is to terminate execution of the body of the smallest loop statement in which it appears, 
and to start the next cycle of that loop (if any). . 


11.5.4 Break Statement 


The break statement has the form 
break 
Its effect is to terminate execution of the smallest loop statement in which it appears. Execution 
continues with the statement following that loop. 
For example, 


sum: int := 0 : 
for x: int in arraylint$elements(a) do 
sum := sum + x 
if sum >= 100 
then sum := 100 break end 
end 


computes the minimum of 100 and the sum of the integers in a. Note that execution of the break 


Statement will terminate both the iterator and the for loop, continuing with the statement following 


the for loop. 


11.6 Tagcase Statement 


The tagcase statement is a special statement provided for decomposing oneof and variant 
objects. Recall that a oneof or variant type is a discriminated union, and each object contains a tag 
and some other object called the value (see Sections 7.12 and 7.13). The tagcase statement permits 
the selection of a body to perform based on the tag of the object. 


The form of the tagcase statement is 
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tagcase expression 
tag_arm { tag_arm } 
f others : body ] 
end 
where 
tag_arm ::= tag name,... [ ( idn: type_spec ) ] : body 
The expression must evaluate to a oneof or variant object. The tag of this object is then matched 
against the names on the tag_arms. When a match is found, if a declaration (idn: type_s pec) exists, 
the value component of the object is assigned to the local variable idn. The matching body is then 
executed; idn is defined only in that body. If no match is found, the body in the others arm is 
executed. 

In a syntactically correct tagcase statement, the following constraints are satisfied. The type 
of the expression must be some oneof or variant type, T. The tags named in the tag_arms must be 
a subset of the tags of T, and no tag may occur more than once. If all tags of T are present, there 
is no others arm; otherwise an others arm must be present. Finally, on any tag_arm containing a 
declaration (idn: type_spec), type_spec must equal the type specified as corresponding in T to the 
tag or tags named in the tag_arm. 

An example of a tagcase statement is 

pair = structicar: int, cdr: int_list] 


x: oneoflpair: pair, empty: null] 


while true do 
tagcase x 
tag empty: return(false) 
tag pair (p: pair): If p.car =i 
then return(true) 
else x := down(p.cdr) 
end 
end 
end 


This statement might be used in a list (of integers) operation that determines whether some given 


integer (é) is on the list. 


60 Return Statement §11.7 


11.7 Return Statement 


The form of the return statement is: 
return [ ( expression , ... ) ] 
The return statement terminates execution of the containing procedure or iterator. If the return 
statement is in a procedure, the type of each expression must be included in the corresponding 
return type of the procedure. The expressions (if any) are evaluated from left to right, and the 
ob jects obtained become the results of the procedure. If the return statement occurs in an iterator 
no results can be returned. 
For example, inside a procedure p with type 
proctype (...) returns (int, char) 
the statement 
return(3, 'a’) 


is legal and returns the two result ob jects 3 and ‘a’. 
11.8 Yield Statement 


Yield statements may occur only in the body of an iterator. The form of a yleld statement is: 
yleld [ ( expression , ... ) ] . 
It has the effect of suspending operation of the iterator, and returning control to the invoking for 
statement. The values obtained by evaluating the expressions (left to right) are passed to the for 
Statement to be assigned to the corresponding list of identifiers. The type of each expression must 


be included in the corresponding yield type of the iterator. 


12. Exception Handling and Exits 


A routine is designed to perform a certain task. However, in some cases that task may be 
impossible to perform. In such a case, instead of returning normally (which would imply successful 
performance of the intended task), the routine should notify its caller by signalling an exception, 


consisting of a descriptive name and zero or more result ob jects. 
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For example, the procedure stringSfetch takes a string and an integer index and returns the 
character of the string with the given index. However, if the integer is not a legal index into the 
String, the exception bounds is signalled instead. The type specification of a routine contains a 
description of the exceptions it may signal; for example, string$fetch is of type 

proctype (string, int) returns (char) signals (bounds) 

The exception handling mechanism consists of two parts, the signalling of exceptions and the 
handling of exceptions. Signalling is the way_a routine notifies its caller of an exceptional 
condition; handling is the way the caller responds to such notification. A signalled exception 
always goes to the immediate ¢aller, and the exception must be handled in that caller. When a 
routine signals an exception, the current activation of that routine terminates and the 
corresponding invocation (in the caller) is said to raise the exception. When an invocation raises 
an exception, control immediately transfers to the closest applicable handler. Handlers are attached 
to statements; when execution of the handler completes, control passes to the statement following 
the one to which the handler is attached. 

The exception failure serves as a general catch-all error indication. When raised, it implies 
that some lower-level abstraction has failed in an unexpected (and possibly catastrophic) way. 
Failure is accompanied by a string result explaining the reason for the failure. All routines can 
potentially signal failure. Failure is implicitly part of all routine headings and routine types; a 


signals clause must not list failure explicitly. 
12.1 Signal Statement 


An exception is signalled with a signal statement, which has the form: 
signal name [ ( expression , ... } ] 
A signal statement may appear anywhere in the body of a routine. The execution of a signal 
Statement begins with evaluation of the expressions (if any), from left to right, to produce a list of 
exception results. The activation of the routine is then terminated. Execution continues in the 
caller as described in Section 12.2 below. 
The exception name must be either one of the exception names listed in the routine heading, 
or failure. If the corresponding exception specification in the heading has the form 
name(Ty, ..., Tp) 
then there must be exactly n expressions in the signal statement, and the type of the ith expression 


must be included in T;. If the name is failure, then there must be exactly one expression present, 
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of type string. 
The following useless procedure contains a number of examples of signal statements: 


Signaller = proc (i: int) returns (int) signals (zero, negativelind) 
if i < 0 then signal negative(-i) 
elseif i > 0 then return(i) 
elself i = 0 then signal zero 
else signal failure("unreachable statement executed!*) 
end 
end signaller 


12.2 Except Statement 


When a routine activation terminates by signalling an exception, the corresponding invocation 
(the text of the call) is said to raise that exception. By attaching handlers to statements, the caller 
can specify the action to be taken when an exception is raised. 

A statement with handlers attached is called an except statement, and has the form: 

statement except { when_handler } 
[ others_handler } 
end 
where 


when_handler ::s whenname.,... [ (decl,... »]: body 


| when name, ... (*) : body 


others_handler ::= others [ ( idn : type_spec ) }: body 
Let S be the statement to which the handlers are attached, and let X be the entire except 
‘statement. Each when_handler specifies one or more exception names and a body. The body is 
executed if an exception with one of those names is raised by an invocation in S. All of the names 
listed in the when_handlers must be distinct. The optional others_handler is used to handle all 
exceptions not explicitly named in the when_handlers. The statement S can be any form of 
statement, and can even be another except statement. 

If, during the execution of 5, some invocation in S raises an exception E, control immediately 
transfers to the closest applicable handler; i.e., the closest handler for £ that is attached to a 
Statement containing the invocation. When execution of the handler completes, control passes to 
the statement following the one to which the handler is attached. Thus if the closest handler is 


attached to 5, the statement following X is executed next. If execution of S completes without 
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raising an exception, the attached handlers are not executed. 

An exception raised inside a handler is treated the same as any other exception: control passes 
to the closest handler for that exception. Note that an exception raised in some handler attached to 
5 cannot be handled by any handler attached to $; either the exception is handled within the 
handler, or it is handled by some handler attached to a statement containing X. 

We now consider the forms of handlers in more detail. The form 

when name .,... [ (deci, ...) J : body 
is used to handle exceptions with the given names when the exception results are of interest. The 
optional declared variables, which are local to the handler, are assigned the exception results before 
the body is executed. Every exception potentially handled by this form must have the same 
number of results as there are declared variables, and the types of the results must equal the types 
of the variables. The form 

when name ,... ( ¢ ) : body 
handles all exceptions with the given names, regardless of whether or not there are exception 
results; any actual results are discarded. Hence exceptions with differing numbers and types of 
results can be handled together. 

The form 

others [ ( idn : type_spec ) ] : body 
is optional, and must appear fast in a handler list. This form handles any exception not handled 
by other handlers in the list. If a variable is declared, it must be of type string. The variable, 
which is local to the handler, is assigned a lower case string representing the actual exception name; 
any results are discarded. . 

Note that exception results are ignored when matching exceptions to handlers; only the names 
of exceptions are used. Thus the following is illegal, in that int$div signals zero_divide without 


any results, but the closest handler has a declared variable: 


begin 
y: int := 0 
x: Int:=3/y * 
except when zero_divide (z: ind: return end 
end 


except when zero_divide: return end 
An invocation need not be surrounded by except statements that handle all potential 
exceptions. This policy was adopted because in many cases the programmer can prove that a 


particular exception will not arise. For example, the invocation Int$div(x, 7) will never signal 
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zero_divide. However, this policy does lead to the possibility that some invocation may raise an 
exception for which there is no handler. To avoid this situation, every routine body is contained 
implicitly in an except statement of the form 


begin routine_body end 
except when failure (s: string): signal failure(s) 
others (s: string): signal failure(“unhandled exception: ” ll s) 
end 


Failure exceptions are propagated unchanged; an exception named name becomes 


failure(“unhandled exception: name") 
12.3 Resignal Statement 


A resignal statement is a syntactically abbreviated form of exception handling: 
statement resignal name , ... 
Each name listed must be distinct, and each must be either one of the condition names listed in the 
routine heading, or failure. The resignal statement acts like an except statement containing a 
handler for each condition named, where each handler simply signals that exception with exactly 
the same results. Thus, if the resignal clause names an exception specification in the routine 
heading of the form 
name(T), ..., T,) 
then effectively there is a handler of the form 
when name (x): Ty, «20s Xp T,): signal name(x), ere Xn) 
As for an explicit handler of this form, every exception potentially handled by this implicit handler 
must have the same number of results as declared in the exception specification, and the types of 
the results must equal the types listed in the exception specification. 
As a simple example, if a routine has a signals clause of the form 
signals (underflow, overflow) 
then 


x: real := 3.14.159 « ye y 
resignal underflow, overflow 


is equivalent to 
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x: real := 3.14159 sy ¢ y 
except when underflow: signal underflow 
when overflow: signal overflow 
end 


12.4 Exit Statement 


A local transfer of control can be effected by using an exit statement, which has the form: 

exit name [ ( expression , ... ) ] 
An exit statement is similar to a signal statement except that where the signal statement signals 
an exception to the calling routine, the exit statement raises the exception directly in the current 
routine. An exception raised by an exit statement must be handled (explicitly) by a containing 
except statement with a handler of the form 

when name, ... [ (decl,...) ] : body 
As usual, the types of the expressions in the exit statement must equal the types of the variables 
declared in the handler. The handler must be an explicit one, i.e., exits to the implicit handlers of 
resignal statements or to the implicit failure handler enclosing a routine body are illegal. 

The exit statement and the signal statement mesh nicely to form a uniform mechanism. The 
signal statement can be viewed simply as terminating a routine activation; an exit is then 
performed at the point of invocation in the caller. (Because this exit is implicit, it is not sub ject to 
the restrictions on exits listed above.) 

The following is a simple example of the use of exits in search loops: 


elt: T 
begin 
for elt in array{T]$elements(x) do 
if speciaKelt) then exit found end 
end 
elt := make_new_one(...) % Didn't find one, so make one up 
end except when found: end 
% At this point we have an object and we don’t care how we got it 


12.6 Example 


We now present an example demonstrating the use of exception handlers. We will write a 
procedure, sum_stream, which reads a sequence of signed decimal integers from a character stream 
and returns the sum of those integers. The stream is viewed as containing a sequence of fields 


separated by spaces; each field must consist of a non-empty sequence of digits, optionally preceded 
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by a single minus sign. Sum_stream has the form 
sum_stream = proc (s: stream) returns (int) signals (overflow, 
unrepresentable_integer(string), 
bad_format(string)) 
end sum_stream 

Sum_stream signals overflow if the sum of the numbers or an intermediate sum is outside the 

implemented range of integers. Unrepresentable_integer is signalled if the stream contains an 

individual number that is outside the implemented range of integers. Bad_format is signalled if 

the stream contains a field that is not an integer. 

We will use the getc operation of the stream data type (see Appendix III), whose type is 

proctype (stream) returns (char) signals (end_of_file, not_possible(string)) 
This operation returns the next character from the stream, unless the stream is empty, in which 
case end_of file is signalled. Not_possible is signalled if the operation cannot be performed on the 
given stream (e.g., it is an output stream, or does not allow character operations, etc.) We will 
assume that we are given a stream for which getc is always possible. 

The following procedure is used to convert character strings to integers: 

$2i = proc (s: string) returns (int) signals (invalid_character(char), 
bad_format, 
unrepresentable_integer) 
end S2i 
S2i signals invalid_character if its string argument contains a character other than a digit or a 
minus sign. Bad_format is signalled if the string contains a minus sign following a digit, more 
than one minus sign, or no digits. Unrepresentable_integer is signalled if the string represents an 
integer that is outside the implemented range of integers. 

An implementation of sum_stream is presented in Figure 5. There are two loops within an 
infinite loop: one to skip spaces, and one to accumulate digits for conversion to a number. Notice 
the placement of the inner end_of_file handler. If end_of_file is raised in the second inner loop, 
then the sum is computed correctly, and the first invocation of stream$getc will again raise 
end_of_file. This time, however, the infinite loop is terminated and execution transfers to the 
other end_of_file handler, which then returns the accumulated sum. 

We have placed the remaining exception handlers outside of the infinite loop to avoid 
cluttering up the main part of the algorithm. Each of these exception handlers could also have 


been placed after the particular statement containing the invocation that signalled the 


$12.5 Example 67 


Fig. 5. The sum_stream procedure. 


sum_stream = proc (s: stream) returns (int) signals (overflow, 
unrepresentable_integer(string), 
bad_format(string)) 
sum: int := 0 
num: string 
while true do 
% skip over spaces between values; sum is valid, num is meaningless 
c: char := stream$getc(s) 
while c =’' do 
C := stream$getc(s) 
end 
% read a value; num accumulates new number, sum becomes previous sum 
num := "" 
while c ~=''’ do 
num := string$append(num, © 
C := Stream$getc(s) 
end 
except when end_of_file: end 
% restore sum to validity 
sum := sum + s2i(num) 
end 
except when end_of file: return(sum) 
when unrepresentable_integer: signal unrepresentable_integer(num) 
when bad_format, invalid_character (#): signal bad_format(num) 
when overflow: signat overflow 
end 
end sum_stream 


corresponding exception. The (+) form is used in the handler for the bad_format and 
invalid _character exceptions since the exception results are not used. Note that the overflow 
handler catches exceptions signalled by the int$add procedure, which is invoked using the infix + 
notation. Note also that in this example all of the exceptions raised by sum_stream originate as 
exceptions signalled by lower-level modules. Sum_stream simply reflects these exceptions upwards 
in terms that are meaningful to its callers. Although some of the names may be unchanged, the 
meanings of the exceptions (and even the number of results) are different in the two levels. 

As mentioned above, we have assumed stream$getc never signals not_possible; if it does, then 
sum_stream will terminate, raising the exception 


failure(unhandled exception: not_possible”) 
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13. Modules 


A CLU program consists of a group of modules. Three kinds of modules are provided, one 
for each kind of abstraction we have found to be useful in program construction: 
module ::= { equate } procedure 
| { equate } iterator 
| { equate } cluster 
Procedures support procedural abstraction, iterators support control abstraction, and clusters 
support data abstraction. | 
A module defines a new scope. The identifiers introduced in the equates (if any) and the 
identifier naming the abstraction (the module name) are local to that scope (and therefore may not 
be redefined in an inner scope). Abstractions implemented by other modules are referred to by 
using non-local identifiers. The system will provide some means of determining what abstractions 
are meant by these non-local identifiers; one such mechanism is defined in Section 4. 
The existence of an externally established meaning for an identifier does not preclude a local 
definition for that identifier. Within a module, any identifier may be used in a purely local 
fashion or in a purely non-local fashion, but no identifier may be used in both ways. 


Example programs appear in Appendix IV. 
13.1 Procedures 


A procedure performs an action on zero or more arguments, and terminates returning zero or 
more results. A procedure supports a procedural abstraction: a mapping from a set of input 
objects to a set of result objects, with possible modification of some of the input objects. A 
procedure may terminate in one of a number of conditions; one of these is the normal condition, 
while others are exceptional conditions. Differing numbers and types of results may be returned in 
the different conditions. 

The form of a procedure is 


idn = proc [ parms ] args [ returns ] [ signals | [ where ] 


routine_body 
end idn 


where 
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args se ( [ deci, ... ) 
returns z= returns ( type spec ,... ) 
signals zz signals ( exception , ... ) 


exception = name [ ( type_spec , ... ) ] 
routine_body ::= { equate } 


{ own_var } 


{ Statement } 

In this section we discuss non-parameterized procedures. For a non-parameterized procedure, 
the parms and where clauses are missing. Parameterized modules are discussed in Section 13.4. 
Own variables are discussed in Section 13.5. 

The heading of a procedure describes the way in which the procedure communicates with its 
caller. The args clause specifies the number, order, and types of arguments required to invoke the 
procedure, while the returns clause specifies the number, order, and types of results returned when 
the procedure terminates normally (by executing a return statement or reaching the end of its 
body). A missing returns clause indicates that no results are returned. 

The signals clause names the exceptional conditions in which the procedure can terminate, 
and specifies the number, order, and types of result objects returned in each condition. In addition 
to the. conditions explicitly named in the signals clause, any procedure can terminate in the failure 
condition. The failure condition returns with one result, a string object. All names of exceptions 
in the signals clause must be distinct, and none can be failure. 

A procedure is an object of some procedure type. For a non-parameterized procedure, this 
type is derived from the procedure heading by removing the procedure name, rewriting the formal 
argument declarations with one idn per decl, deleting the names of formal arguments, and finally, 
replacing proc by proctype. 

As was discussed in Section 9.3, the invocation of a procedure causes the introduction of the 
formal variables, and the actual arguments are assigned to these variables. Then the procedure 
body is executed. Execution terminates when a return statement or a signal statement is executed, 
or when the textual end of the body is reached. If a procedure that should return results reaches 
the textual end of the body, the procedure terminates in the condition 

failure(“no return values”) 


At termination the result objects, if any, are passed back to the invoker of the procedure. 
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The idn following the end of the procedure must be the same as the idn naming the 
procedure. 


Examples of procedures are given in Appendix IV. 
13.2 Iterators 


An iterator computes a sequence of items, one item at a time, where an item is a group of zero 
or more objects. In the generation of such a sequence, the computation of each item of the 
sequence is usually controlled by information about what previous items have been produced. Such 
information and the way it controls the production of items is local to the iterator. The user of the 
iterator is not concerned with how the items are produced, but simply uses them (through the for 
Statement) as they are produced. Thus the iterator abstracts from the details of how the production 
of the items is controlled; for this reason, we consider an iterator to implement a control abstraction. 
Iterators are particularly useful as operations of data abstractions that are collections of ob jects 
(e.g., sets), since they may produce the objects in a collection without revealing how the collection is 
represented. 

An iterator has the form 


idn = iter [ parms ] args [ yields ] [ signals ] [ where ] 
routine_body 
end idn 


where 
yields ::= ylelds ( type_spec ,... ) 
In this section we discuss non-parameterized iterators, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 13.4. Own variables are discussed in 
Section 13.5. 
The form of an iterator is very similar to the form of a procedure. There are only two 
differences: 


1. An iterator has a yields clause in its heading in place of the returns 
clause of a procedure. The yields clause specifies the number, order, 
and types of objects yielded each time the iterator produces the next 
item in the sequence. If zero objects are yielded, then the yields clause 
is omitted. 


2. Within the iterator body, the yield statement is used to present the next 
item in the sequence. An iterator terminates in the same manner as a 
procedure (note that it may not return any results). 


$13.2 Iterators n 


An iterator is an object of some iterator type. Its type can be derived from its heading by 
removing the iterator name, rewriting the formal argument declarations with one idn per decl, 
deleting the formal argument names, and finally, replacing iter by itertype. 

An iterator can be invoked only by a for statement. The execution of iterators is described in 
Section 11.5.2. 

An example of an iterator is 


Splits = iter (s: string) yields (string, string) 
for i: int in int¢from_to(0, string$size(s)) do 
yield(string$substr(s, 1, i), stringSrest(s, i + 1) 
-end 
end splits 


Additional examples of iterators are given in the next section. 


Remarks 

Iterators provide a useful mechanism for abstracting from the details of control. Furthermore, 
they permit for statements to iterate over the objects of interest, rather than requiring a mapping 
from the integers to those ob jects. 

It is important to realize that the argument objects passed to the iterator are also accessible in 
the body of the for loop controlled by the iterator. If some argument object is mutable, and the 
iterator modifies it, the change can affect the behavior of the for loop body, and vice-versa. Such 
changes can be the cause of program errors. 

As a general principle, an iterator should not modify its argument objects. There are some 
examples, however, where modification is appropriate. For example, an iterator that produces the 
characters from an input stream would advance the stream "window" (the currently accessible 
character) on each iteration. 

Also as a general principle, the for loop body should not modify the iterator’s argument 
objects. Again, occasional examples exist where modification is desirable. In programming such 
examples, the programmer must ensure that the iterator will still behave correctly in spite of the 


modifications. 
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13.3 Clusters 


A cluster is used to implement a new data type, distinct from any other built-in or user-defined 
data type. A data type (or data abstraction) consists of a set of objects and a set of primitive 
operations. The primitive operations provide the most basic ways of manipulating the objects; 
ultimately every action that can be performed on the objects must be expressed in terms of the 
primitive operations. Thus the primitive operations define the lowest level of observable ob ject 
behavior. | 

The form of a cluster is 


idn = cluster [ parms ] is idn,... [ where ] 


cluster_body 
end idn 


where 
{ equate } rep = type_spec { equate } 


{ own_var } 


routine { routine } 


cluster_body :: 


routine = procedure 
| iterator 


In this section we discuss non-parameterized clusters, in which the parms and where clauses are 
missing. Parameterized modules are discussed in Section 13.4. Own variables are discussed in 
Section 13.5. 

The primitive operations are named by the list of idns following the reserved word Is. All of 
the idns in this list must be distinct. 

To define a new data type, it is necessary to choose a concrete representation for the objects of 
the type. The special equate 

rep = type_spec 

within the cluster body identifies type_spec as the concrete representation. Within the cluster, rep 
may be used as an abbreviation for type_spec. 

The identifier naming the cluster is available for use in the cluster body. Use of this 
identifier within the cluster body permits the definition of recursive types (an example is given 
below). 
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In addition to specifying the representation of ob jects, the cluster must implement the primitive 
operations of the type. The operations may be either procedural or contro! abstractions; they are 
implemented by procedures and iterators, respectively. Most of the routines in the cluster body 
define the primitive operations (those whose names are listed in the cluster heading). Any 
additional routines are Aidden: they are private to the cluster and may not be invoked by users of 
the abstract type. All the routines must be named by distinct identifiers; the scope of these 
identifiers is the entire cluster. 

Outside the cluster, the type’s objects may only be treated abstractly (i.e., manipulated by using 
the primitive operations). To implement the operations, however, it is usually necessary to 
manipulate the objects in terms of their concrete representation. It is also convenient sometimes to 
manipulate the objects abstractly. Therefore, inside the cluster it is possible to view the type’s 
objects either abstractly or in terms of their representation. The syntax is defined to specify 
unambiguously, for each variable that refers to one of the type’s objects, which view is being taken. 
Thus, inside a cluster named T, a declaration 

ve, 
indicates that the object referred to by v is to be treated abstractly, while a declaration 

w: rep 
indicates that the object referred to by w is to be treated concretely. Two primitives, up and down, 
are available for converting between these two points of view. The use of up permits a type rep 
ob ject to be viewed abstractly, while down permits an abstract object to be viewed concretely. For 
example, given the declarations above, the following two assignments are legal: 


Vv := up(w) 
w := down(v) 


Only routines inside a cluster may use up and down. Note that up and down are used merely to 
inform the compiler that the ob ject is going to be viewed abstractly or concretely, respectively. 

A common place where the view of an object changes is at the interface to one of the type's 
operations: the user, of course, views the ob ject abstractly, while inside the operation, the ob ject is 
viewed concretely. To facilitate this usage, a special type specification, cvt, is provided. The use 
of cvt is restricted to the args, returns, yields and signals clauses of routines inside a cluster, and 
may be used at the top level only (eg., array{cvt) is illegal). When used inside the args clause, it 
means that the view of the argument object changes from abstract to concrete when it is assigned 


to the formal argument variable. When cvt is used in the returns, yields, or signals clause, it 


74 Clusters $13.3 


means the view of the result object changes from concrete to abstract as it is returned (or yielded) 
to the caller. Thus cvt means abstract outside, concrete inside: when constructing the type of a 
routine, cvt is equivalent to the abstract type, but when type-checking the body of a routine, cvt is 
equivalent to the representation type. 

The cvt form does not introduce any new ability over what is provided by up and down. It 
is merely a shorthand for a common case. In its absence, the heading of each routine would have 
to be written using the abstract type in place of cvt. Then inside the routine, additional variables 
of type rep would be declared, the argument objects assigned to these variables using down, and 
each return, yield, or signal statement would use up explicitly. The use of cvt simply causes the 
appropriate up or down to be performed automatically, and avoids the declaration of additional 
variables. . 

The type of each routine is derived from its heading in the usual manner, except that each 
occurrence of cvt is replaced by the abstract type. 

Inside the cluster, it is mot necessary to use the compound form (type_spec$op_name) for 
naming locally defined routines. Furthermore, the compound form cannot be used for invoking 
hidden routines. 

The identifier following the end must match the identifier naming the cluster. 

Some examples of clusters are shown in Figure 6. The first example implements (part of) a | 
complex number data type. This data type may be implemented using either x and y coordinates, 
or rho and theta coordinates; the cluster shown uses x and y coordinates. Note that the create, 
get_x, and get_y operations might signal an exception if rho/theta coordinates were used; therefore 
these exceptions are listed in the headings, even though in this implementation the exceptions will 
not be signalled. The coordinates of a complex number can be queried using the get operations 
explicitly, or by using the special syntax, e.g., 

a.theta 
No sef operations are provided, since complex numbers should be immutable like other numbers 
(integers, reals, etc.). Other operations on complex numbers are the usual arithmetic ones (only add 
is shown), and equal, similar, and copy (these are discussed in the remarks section below). (Note: we 
have assumed that square_root and arctangent2 exist in the library.) 

The second example cluster implements lists of integers. These lists are immutable, like pure 
lists in LISP. The implementation is recursive: the representation type refers to the abstract type. 


Notice the elements operation, which produces all integers in the list in order; it is an example of a 
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recursive iterator. 

The final example is sets of integers. The sets are mutable: operations insert and delete 
modify sets. Again note the elements iterator, which produces all elements of a set in some 
unspecified order. Also note the use of is_in in insert; since is_in requires an abstract ob ject as its 


argument, up is used to provide one. 


Remarks 

The main reason CLU was developed was to support the use of data abstractions. Use of data 
abstractions leads to an object-oriented style of programming, in which concerns about data are 
primary and serve to organize program structure. It requires some effort to learn to program in 
this style, but the effort is worthwhile because the resulting programs are more modular, and easier 
to modify and maintain. 

A cluster permits all knowledge about how a data abstraction is being implemented to be kept 
local to the cluster. This localization permits the correctness of an implementation to be established 
by examining the cluster alone. Part of such a correctness proof involves showing that only legal 
representations are generated by the cluster. For example, in the int_set cluster above, not all 
arrays are legal int_set representations; only those without duplicate elements are legal. 
Information about what constitutes a legal representation is described during program verification 
by stating the concrete invariant. Each operation must preserve this invariant for each ob ject that 
it manipulates of the abstract type. This requirement applies at all return and signal statements 
in operations, and also at yield statements in iterator operations. 

When defining a new data type, it is important to provide a set of primitive operations 
sufficient to permit all interesting manipulations of the objects. There is no reason to attempt to 
define a minimal set, however; frequently used operations can be made operations of the cluster 
even if they could be implemented in terms of other operations. 

Operations that will frequently be required are copy, equal, and similar. These operations are 
needed if the type being defined is intended for general use, since without these operations, the use 
of the type within another type’s concrete representation is somewhat limited. For example, 
array{T]$copy cannot be used unless T has a copy operation. In addition, most types should 


provide I/O operations as discussed in Appendix Iil. 
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complex = cluster Is create, add, get_x, get_y, get_rho, get_theta, equal, similar, copy 
rep = struct(x, y: reaf) 


create = proc (x, y: rea) returns (ev) signals (overflow, underflow) 
return(rep${x: x, y: y)) 
end create 


add = proc (a, b: cvt) returns (cv0 signals (overflow, underflow) 
returnrep${x: a.x + b.x, y: ay ¢ b.y)) 
resignal overflow, underflow 
end add 


get_x = proc (c: cvt) returns (read signals (overflow, underflow) 
returnc.x) 
end get_x 


get_y = proc (c: cvt) returns (real signals (overflow, underflow) 
returnic.y) 
ond get_y 


get_rho = proc (c: cv returns (real) signals (overflow, underflow) 
return(square_rootic.x ¢ cx + Cy # Cy) 
resignal overflow, underflow 
end get_rho 


gettheta = proc (c: cvt) returns (rea) signals (overflow, underflow) 
returniarctangent2(c.x, c.y)) 
resignal overflow, underflow 
end get_theta 


% Note that the equal operation of the rep type tests equality of corresponding real components, 
% not identity of rep objects. 


equal = proc (cl, c2: cvt) returns (boo) 
returnicl = c2) 
end equal 


similar = proc (cl, c2: ev® returns (boodD 
returnicl = c2) 
end similar 


copy = proc (c: complex) returns (complex) 
return(c) 


end copy 
end complex. 


$13.3 Clusters 


int_list = cluster Is create, cons, car, cdr, is_in, is_empty, elements, equal, similar, copy 


rep = oneof(pair: pair, empty: nutl) 
pair = structicar: int, cdr: int_list] 


create = proc () returns (cv 
return(rep$make_empty(nil)) 
end create 


cons = proc (i: int, Ist: int_list) returns (cvt 
return(rep$make_pair(pair${car: i, cdr: tst})) 
end cons 


car = proc (Ist: cvt) returns (int) signals (empty) 
tagcase Ist 
tag pair (p: pair): return(p.car) 
tag empty: signal empty 
end 
end car 


cdr = proc (Ist: cvt) returns (int_list) signals (empty) 
tagcase Ist 
tag pair (p: pair): return(p.cdr) 
tag empty: signal empty 
end 
end cdr 


is_in = proc (Ist: cvt, i: int) returns (boo! 
while true do 
tagcase Ist 
tag empty: returnifalse) 
tag pair (p: pair): if p.car =i 
then return(true) 
else Ist := down(p.cdr) 
end 
end 
end 
end is_in 


is_empty = proc (Ist: cvt) returns (bool 
return(rep$is_empty(Ist)) 
end is_empty 
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elements = iter (Ist: cv yields (int) 
tagcase Ist 
tag pair (p: pair): yleld&(p.car) 
for i: int in elements(p.cdr) do 


-yleici) 
end 
tag empty: 
end 
end elements 


% Note that the equal operation of the rep type tests equality of corresponding list elements, not 
% identity of rep ob jects. 


equal = proctistl, Ist2: cv?) returns (boo) 
return(istl = tst2) 
end equal 


similar = proc (Isti, Ist2: cv) returns (boo? 
return(Ist] = ist2) 
end similar 


copy = proc (Ist: int_list) returns (int_list) 
returnilst) 


end copy 
end int_list 


int_set = cluster Is create, insert, delete, is_in, size, elements, equal, similar, copy 
rep = arraylint) 


create = proc () returns (cevd 
return(rep$new()) 
end create 


insert = proc (s: cvt, i: Ind 
if ~ is_in(up(s), i) then rep$addh(s, i) end 
end insert 
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delete = proc (s: cvt, i: Ind 
for j: int in rep$indexes(s) do 
ifi-estj) 
then sl j) := rep$top(s) 
rep$remh(s) 
return 
end 
end 
end delete 


- is_in = proc (s: cvt, i: ind returns (boo) 
for j: int In rep$elements(s) do 
if i = j then returnitrue) end 
end 
return false) 
end is_in 


Size = proc (s: cvt) returns (ind 
return(rep$size(s)) 
end size 


elements = iter (s: cvt) yields (int 
for i: int in rep$elements(s) do 
yieldi) 
end 
end elements 


equal = proc (sl, s2: cvt) returns (bool) 
return(sl = s2) 
end equal 


similar = proc (sl, s2: int_set) returns (bool) 
if size(s]) w= size(s2) then returnifalse) end 
for i: int in elements(sl) do 
if ~ is_in(s2, i) then return(false) end 
end 
return(true) 
end similar 


copy = proc (s: cvt) returns (cvt) 
return(rep$copy(s)) 
end copy 


end int_set 
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In many earlier sections, we have discussed the use of special syntactic forms for invoking 
operations, and have described how operations must be named and defined in order to make use of 
these syntactic forms. The use of such forms is quite unconstrained: the special form is translated 
to an invocation, and is legal if the invocation is legal. 

Our reason for not imposing more syntactic constraints on operator overloading is that such 
constraints only capture a small part of what it means to use operator overloading correctly. For 
example, to overload "=" correctly, the equal operation should be an equivalence relation satisf ying 
the substitution property; i.e., if two objects are equal, then one can be substituted for the other 
without any detectable difference in behavior. In the sections where special syntactic forms are 
described, we have discussed in each case what constitutes proper usage. 

Overloading operator symbols is not the only place where care must be taken to ensure that the 
new definition agrees with common usage; the same care must be taken when redefining common 
Operation names. For example, the copy operation should provide a “copy” of its input object, such 
that subsequent changes made to either the old or the new object do not affect the other. In the 
case of an immutable type, like complex_number above, in which sharing between two ob jects will 
never be visible to the using program, copy can simply return its input object. Ordinarily, however, 
copy should copy its input objects, including each component (using the copy operation of the 
component's type), as is done in the implementation of int_set. | 

_ The equal operation should return true if its two input objects are the same abstract ob ject. 
This is necessary to satisf y the substitution property: if two objects are equal, then using one in 
place of the other in a computation will not alter the computation. Thus, implementing equal 

‘properly requires a thorough understanding of both the abstraction being implemented and the 
representation being used. Usually two mutable objects are equal only if they are the exact same 
ob ject in the CLU universe; e.g., see int_set$equal above. For immutable ob jects, the contents of 
the ob ject is usually all that matters; e.g., see complex$equal and int_list$equal above. 

The similar operation should return true only if its two input objects (both of the same type) 
have “equivalent state”. This means that any query made about information in two similar ob jects 
immediately after they were determined to be similar would provide an equivalent answer for 
either of the two objects (ie. the answers would be similar). Note that similar is a weaker 
condition than equal: two objects are equal if they are the same abstract objects, and so of course 
they are similar for all time. Equal and similar return different results only for mutable types, 


because only mutable types have objects whose state can change. Copy and similar should be 
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related as follows for any type T: 
VxeT [ T$similar(x, T$copy(x)) ] 
With the exception of set and store operations, procedures that define operator symbols, copy, 
similar, and the I/O operations should never modify their input objects in a way that the user of 
the object can detect. This rule does not prohibit “benevolent” side-effects, i.e., modifications that 


speed up future operations without affecting behavior in any other way. 
13.4 Parameterized Modules 


Procedures, iterators, and clusters may all be parameterized. Parameterization permits a set of 
related abstractions to be defined by a single module. Recall that in each module heading there is 
an optional parms clause and an optional where clause. The presence of the parms clause 
indicates that the module is parameterized; the where clause states certain constraints on 
permissible actual values for the parameters. 

The form of the parms clause is 

{ parm,...] 
where 

parm ::= idn,... : type_spec 

| idn,...: type 

Each parameter is declared like an argument. However, only the following types of parameters are 
‘legal: Int. real, bool, char, string, null, and type. Parameters are limited to these types because 
the actual values for parameters are required to be constants that can be computed at compile-time. 
This requirement ensures that all types are known at compile-time, and permits complete 
compile-time type-checking. 

In a parameterized module, the scope rules permit the parameters to be used throughout the 
remainder of the module. Thus they can be used in defining the types of arguments and results, 
eg., 

p = proc [t: type] (x: t) returns (1) 

To use a parameterized module, it is first necessary to instantiate it; that is, to provide actual, 
constant values for the parameters. (The exact forms of such constants were discussed in 
Section 8.3.) The result of instantiation is a procedure, iterator, or type (where the parameterized 
module was a procedure, iterator, or cluster, respectively) that may be used just like a 


non-parameterized module of the same kind. For each distinct instantiation, (ie., for each distinct 
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list of actual parameters), a distinct procedure, iterator, or type is produced. 

The meaning of a parameterized module is most easily understood in terms of rewriting. 
When the module is instantiated, the actual parameter values are substituted for the formal 
parameters throughout the module, and the parms clause and where clause are deleted. The 
resulting module is a regular (non-parameterized) module. In the case of a cluster some of the 
operations may have additional parameters; further rewriting will be performed when these 
operations are used. . 

In the case of a type parameter, constraints on permissible actual types can be given in the 
where clause. The where clause lists a set of operations that the actual type is required to have, 
and also specifies the type of each required operation. The where clause constrains the 
parameterized module as well: the only primitive operations of the type parameter that can be used 
are those listed in the where clause. | 

The form of the where clause is 

where = where restriction , ... 
where 


restriction ::= idn has oper_decl, ... 


| idn in type_set 
© oper_decl ::= op_name ,... : type_spec 
op_name ::= name [ { constant ,... ] ] 
type_set := { idn| idn has oper_decl, ... { equate } ) 
| idn 
There are two forms of restrictions. In both forms, the initial idn must be a type parameter. 
The has form lists the set of required operations directly, by means of oper_decis. The type_s pec 
in each oper_decl must name a routine type. Note that if some of the type’s operations are 
parameterized, particular instantiations of those operations must be given. The In form requires 
that the actual type be a member of a type_set, a set of types having the required operations. The 
two identifiers in the type_set- must match, and the notation is read like set notation; e.g., 
{tlt has f:..} 
means “the set of all types ¢ such that ¢ has /...". The scope of the identifier is the type_set. 
The in form is useful because an abbreviation can be given for a type_set via an equate. If it 
is helpful to introduce some abbreviations in defining the type_set, these are given in the optional 


equates within the type_set. The scope of these equates is the type_set. 
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A routine in a parameterized cluster may have a where clause in its heading, and can place 
further constraints on the cluster parameters. For example, any type is permissible for the array 
element type, but the array similar operation requires that the element type have a similar 
operation. This means that array{T] exists for any type T, but that arraylT]$similar exists only 
when T$similar exists. Note that a routine need not include in its where clause any of the 


restrictions included in the cluster where clause. 


Two examples of parameterized clusters are shown in Figure 7. The first defines the set type 
generator. This cluster is similar to int_set, presented in the previous section. The main difference 
is that everywhere that integer elements were assumed, now the parameter f is used. The set type 
generator has a where clause that requires the element type to provide an equal operation; in 
addition, the similar operation imposes an additional constraint on the element type by requiring a 
similar operation. Thus set{X] is legal if X has an equal operation; but setl X]$simitar can be used 
only if X also has a similar operation. Note the procedure is_in_sim; it is a hidden routine of this 
implementation. Also note the use of the type_set sim_type. 

The state of a set object is the set of abstract objects currently in the set. What matters is the 
identity of the objects, not their state. This should help in understanding why equal, similar, and 
copy are written as they are. Notice that we have two new operations, similar! and copy!l. Similarl 
returns true when two objects have equal state (in the abstract sense), whereas similar returns true 
when they have similar state. Copyl is to similar! what copy is to similar, i.e., 
T$similarl(T$copyl(x), x) should always be true. In general, mutable type generators that behave 
like collections should provide similar! and copy! to ensure that types obtained from the generator 
can be used as part of the concrete representation of other types. 

The second example is a /ist type generator, which is similar to int_list in the previous section. 
List does not place any constraints in its type parameter. Therefore any element type is permissible 
for lists, including type any. Note that the types generated by the /ist type generator are 
immutable. The state of a list is considered to be the ordered set of objects in the list, where only 
the identity of the objects matters. Lists are immutable even if the objects in the lists are mutable, 
because the state of a list never changes. 

Confusion can arise unless the designer and implementor of a data type have in mind a clear 
idea of exactly what constitutes the state of the objects of the type they are defining; it must be 


resolved in which cases it is only the identity of the components that matters, and in which cases 
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Fig. 7. More Example Clusters 


set = cluster [t: type] is create, insert, delete, is_in, size, 
elements, equal, similar, similarl, copy, copy! 
where t has equal: proctype (t, t) returns (bood 


rep = arrayit) 
sim_type = {s|s has similar: proctype (t,t) returns (bood) 


create = proc () returns (cev® 
return reptnew()) 
end create 


insert = proc (s: cvt, v: 0 
if ~ is_in(up(s), v) then rep$addh(s, v) end 
end insert 


delete « proc (s: cvt, v: 0) 
for j int in repSindexes(s) do 
tv-sdsj) 
then sf j) := rep$tapts) 
reptremh(s) 
return 
end 
end : ». 
end delete £ 


is_in = proc (s: cvt, v: t) returns (boo! 
' "for u: t in repSelements(s) do 
fu = v then return(true) end 
end 
return false) 
end is_in 


4s_in_sim = proc (s: cvt, v: 0 returns (boo? where t in sim_type 
for u: t in repSelements(s) do 
if ($similar(u, v) then return(true) end 
end . 
return faise) 
-end is_in_sim 


size « proc (s: cv¥ returns (ind 
return rep$size(s)) 
end size 
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elements = iter (s: cvt) yields (0) 
for v: t in rep$elements(s) do 
yleld(v) 
end 
end elements 


equal = proc (sl, s2: cvt) returns (bool) 
returns! = s2) 
end equal 


similar = proc (sl, s2: set{t]) returns (bool) where ¢ in sim_type 
if size(sl) ~= size(s2) then return(false) end 
for u: ¢ in elements(sl) do 
if ~ is_in_sim(s2, u) then returnifalse) end 
end 
return(true) 
end similar 


similarl = proc (sl, s2: set{t]) returns (bool) 
If size(sl) ~= size(s2) then returnifalse) end 
for u: t in elements(sl) do 
if ~ is_in(s2, u) then return(false) end 
end 
return( true) 
end similarl 


copy = proc (s: cvt) returns (cv) where t has copy: proctype (t) returns (t) 
return rep$copy(s)) 
end copy 


copy! = proc (s: évt returns (cv) 
return rep$copyl(s)) 
end copyl 


end set 
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list = cluster [t: type] Is create, cons, car, cdr, is_in, is_empty, elements, equal, similar, copy 


rep = oneof{ pair: pair, empty: null] 
pair = structicar: ¢, cdr: list(t]) 


create «= proc () returns (cvt) 
return(rep$make_empty(niD) 
end create 


cons = proc (v: t, Ist: list[t]) returns (cvt 
return rep$make_pair(pair${car: v, cdr: Ist))) 
end cons 


car = proc (Ist: cvt) returns (t) signals (empty) 
tagcase Ist 
tag pair (p: pair): returm(p.car) 
tag empty: signal empty 
end 
end car 


cdr = proc (Ist: cv returns (listit}) signals (empty) 
tagcase Ist 
tag pair (p: pair): return(p.cdr) | 
tag empty: signal empty 
end 
end cdr 


is_in = proc (Ist: cvt, v: t) returns (boo) where t has equal: proctype (t, t) returns (booD 
while true do 
tagcase Ist 
tag empty: return false) 
tag pair (p: pair): If p.car = v 


then return(true) 
else Ist := downp.cdr) 
end 
end 
end 
end is_in 


is_empty = proc (Ist: cvt) returns (bool) 
return rep$is_empty(tst)) 
end is_empty 
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elements = iter (Ist: cv ylelds (t) 
tagcase Ist 
tag pair (p: pair): yield(p.car) 
for v: t in elements(p.cdr) do 


yleld(v) 
end — 
tag empty: 
end 
end elements 


equal = proc (Istl, Ist2: cvt) returns (bool where t has equal: proctype (t, t) returns (booD 


returni{stl = Ist2) 
end equal 


similar = proc (Istl, Ist2: cv) returns (boo! 
where t has similar: proctype (t, t) returns (booD 


return(rep$similar(Istl, Ist2)) 
end similar 


copy = proc (Ist: cvt) returns (cvt) where t has copy: proctype (t) returns (t) 


return rep$copy(tst)) 
end copy 


end list 
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their state matters as well. 

The position taken in the dist type generator below is that the state of a list consists only of the 
identity of the objects in the list, and does not depend on their state. Hence, these lists are 
immutable. This explains why (ist has'no similar! or copyl operations, and why equal, similar, and 


copy are implemented as they are. 


There are two restrictions on the kinds of constants that can be used in op_names of where 
clauses and type_sets. These restrictions eliminate certain ambiguities that would otherwise arise in 
type-checking. There is no need to understand or remember these restrictions, as the programs 
they affect are fairly bizarre, and have never occurred in practice. The rules are included here 
solely for completeness. 

The first restriction is that no type parameter, and no type identifier introduced in a type_set, 
can be used anywhere in an op_name constant. Thus, if ¢ is a type parameter, an op_name of the 
form “compute arrayit]]" would be illegal. The second restriction deals with the way data 
abstractions depend on each other. If, in the interface of a data abstraction A, some data 
abstraction B is used in an op_name constant, we say that A is “restricted in terms of” B. We 
define r-uses to be the transitive closure of this relation. The second restriction, then, is that an 


abstraction cannot r-use itself. 
13.6 Own Variables 


Occasionally it is desirable to have a module that retains information internally between 
invocations. Without such an ability, the information would either have to be reconstructed at 
every invocation, which can be expensive (and may even be impossible if the information depends 
on previous invocations), or the information would have to be passed in through arguments, which 
is undesirable because the information is then subject to uncontrolled modification in other 
modules. 

Procedures, iterators, and clusters may all retain information through the use of own variables. 
An own variable is similar to a normal variable, except that it retains its denotation from one 
routine activation to the next, including recursive activations. Syntactically, own variable 
declarations must appear immediately after the equates in a routine or cluster body; they cannot 


appear in bodies nested within statements. Own variable declarations have the form 
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own_var ::= own deci 
| own idn : type_spec := expression 


| own decl, ... := invocation 
Note that initialization is optional. 

Own variables are created when a program begins execution, and they always start out 
uninitialized. The own variables of a routine (including cluster operations) are initialized in 
textual order as part of the first invocation of that routine, before any statements in the body of 
the routine are executed. Cluster own variables are initialized in textual order as part of the first 
invocation of the first cluster operation to be invoked (even if the operation does not use the own 
variables). Cluster own variables are initialized before any operation own variables are initialized. 

Aside from the placement of their declarations, the time of their initialization, and the lifetime 
of their denotations, own variables act just like normal variables and can be used in all the same 
places. As for normal variables, attempts to use uninitialized own variables (if not detected at 
compile-time) cause the run-time exception 

failure(uninitialized variable”) 

‘Own variable declarations in different modules always refer to distinct own variables, and 
distinct executions of programs never share own variables (even if the same module is used in 
several programs). Furthermore, own variable declarations within a parameterized module produce 
distinct own variables for each instantiation of the module. For a given instantiation of a 
parameterized cluster, all instantiations of the type's operations share the same set of cluster own 
variables, but distinct instantiations of parameterized operations have distinct routine own 
variables. For example, in the following cluster there is a distinct x and 9 for every type ¢, and a 


distinct z for every type-integer pair (¢, i): 
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C = cluster [t: type] Is ... 
own x: int := init(...) ¢ 2 


P = proc (...) 
own y: ... 
end P 
Q = proc [i: int) (...) 
Own Z: ... 
endQ 
end C 
Own variable declarations cannot be enclosed by an except statement, so care must be 
exercised when writing initialization expressions. If an exception is raised by an initialization 
expression, it will be treated as an exception raised, but not handled, in the body of the routine 
whose invocation caused the initialization to be attempted. This routine will then signal failure to 
its caller (see Section 12.2). In the example cluster above, if procedure P were the first operation of 
Cl string) to be invoked, causing initialization of x to be attempted, then an overflow exception 
raised in the initialization of x would result in P signalling 
failure("unhandled exception: overflow") 


to its caller. 


Remarks 

Own variables are often useful in declaring “constants” that are either derived from 
complicated computations or are otherwise illegal in equates. In almost all such cases, the 
initialization can be attached directly to the declaration. For example, 


own flip: complex := complex$create(0.0, 1.0) 
own primes: sequence int) := table_of _primes() 


However, the data denoted by own variables may also change dynamically, and may contain history 


information, as the following (fairly useless) module demonstrates: 
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delayer = proc [t: type, delay: int) (x: 0 returns (0) signals (not_yet) 


at = arraylt) 

own oldies: at := at$new() 

at$addh(oldies, x) % add to waiting list 

if at$sizeloldies) > delay _ % if delayed long enough 
then oldies.low := 1 % prevent eventual overflow 

return(at$reml(oldies)) % remove and return oldest 

else signal not_yet 
end 


end delayer 
When cluster own variable initialization involves lengthy computations, one own variable can 
be initialized with an (internal) operation call, and the body of that operation can assign values 
directly to the other own variables: 
C = cluster Is ... 


own x: table := own_init() 
own y: table 


own_init = proc () returns (table) 


y=... 


return..) 
end own_init 
end C 

On occasion, when a particular program is known to use exactly one object of a particular 
user-defined type, it is tempting to implement the type such that the sole object is denoted by a 
cluster own variable. In this way, the object need not be passed as an argument to the various 
routines in the computation, many of which do not even use the object directly. This is a poor 
design decision in most cases, because the ways in which the type can be used later are then 
severely restricted. For example, the type cannot then be used in any program requiring several 
ob jects of that type. It is usually better to design types in as general a manner as possible. 

With the introduction of own variables, procedures and iterators become potentially mutable 
objects. If the abstract behavior of a routine depends on history information (as does delayer 
above), then care must be exercised to guarantee that the routine is used correctly in other modules. 
(Ideally, a CLU system should have some method of controlling access to routines.) In general, own 


variables should not be used to modify the abstract behavior of a module. 
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Appendix I - Syntax 


We use an extended BNF grammar to define the syntax. The general form of a production is: 


nonterminal ::= alternative 
| alternative 


| alternative 


The following extensions are used: 


a vse a list of one or more a’s separated by commas: "a" or “a, a” or 
"a, a, a” etc. 
{a} a sequence of zero or more a's: "” or “a” or “a a” etc. 


[a] an optional a: “" or “a”. 
All semicolons are optional in CLU, but for simplicity they appear in the syntax as °;" rather 
than [i]. Nonterminal symbols appear in normal face. Reserved words appear in bold face. All 


other terminal symbols are non-alphabetic, and appear in normal face. 


module 


33 
a 


{ equate } procedure 
| { equate } iterator 


{ equate } cluster 


procedure ss idn = proc [ parms J args [ returns ] [ signals ] [ where ] ; 
routine_body 


end idn ; 
iterator as idn = iter [ parms J args [ yields ] [ signals ] [ where ] ; 
routine_body. 
end idn ; 
cluster = idn = cluster [ parms ] is idn,... [ where ]; 
cluster_body 
end idn ; 
parms z= C parm,... J 
parm 7s idn,...: type 
idn , ... : type_spec 
args ss ( [ deci , ... ) 


$I 


decl 
returns 
yields 
signals 
exception 
where 


restriction 


type_set 


oper_dect 
op_name 


constant 


routine_body 


- cluster_body 


routine 
equate 


own_var 


Syntax 


idn , ... : type_spec 
returns ( type_spec , ... ) 
yields ( type_spec, ... ) 
signals ( exception , = ) 
name [ ( type_spec , ... ) ] 
where restriction , ... 


idn has oper_decl, ... 
idn in type_set 


{ idn | idn has oper_decl,... ; { equate } } 
idn 

op_name , ... : type_spec 

name [ ( constant ,... J ] 

expression 

type_spec 

{ equate } 

{ own_var } 


{ statement } 


{ equate } rep = type_spec ; { equate } 


{ own_var } 


routine { routine } 


procedure 
iterator 


idn = constant ; 

idn = type_set ; 

own deci ; 

own idn : type_spec := expression ; 


own dec] , ... := invocation ; 
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null 
bool 
int 


type_spec 


= 

| 

| 

| real 

| char 

| string 

| any 

| rep 

| cvt 

| array [ type_spec } 
| sequence [ type_spec ] 

| record [ field_spec ,... } 

| struct field_spec ,... ] 

| oneof [ field_spec, ... } 

| variant [ field_spec, ... ] 

| proctype ( [ type_spec , ... ] ) [ returns ] [ signals ] 
| itertype ( [ type_spec , ... ] ) [ yields J [ signals ] 

| idnC constant, ... J 

| idn 


field.spec . i= name,... : type_spec 


§1 


statement 


tag_arm 


Syntax 


decl ; 
idn : type_spec := expression ; 


decl , ... := invocation ; 
idn , ... := invocation ; . 


idn ,... := expression , ... ; 
primary . name := expression ; 
primary [ expression } := expression ; 
invocation ; 
while expression do body end ; 
for [ deci, ... ] In invocation do body end ; 
for [ idn ,... ] in invocation do body end ; 
if expression then body 

{ elseif expression then body } 


[ else body ] 
end; 
tagcase expression 


tag_arm { tag_arm } 

[ others : body ] 

end; 
return [ ( expression , ... ) ]: 
yield [ ( expression , ... ) ] ; 
signal name [ ( expression , s ) ] : 
exit name [ ( expression , ... ) ] ; 


break ; 
continue ; 
begin body end ; 


statement resignal name , ... 


statement except { when_handler } 


[ others_handler ] 
end; 


tag name, ... [ ( idn : type_spec ) ] : body 


when_handler 


others_handler :: 


body 


expression 


Syntax 


when name, ... [ ( dect, ... )] : body 
when name , ... ( ) : body 

others [ ( idn : type_spec ) ] : body 
{ equate } . 

{ statement } 


primary 

( expression ) 

~ expression % 6 (precedence) 
- expression x6 

expression ¢* expression % 65 


we 


4 

4 

4 
3 


expression // expression 
expression / expression 
expression * expression 
expression ll expression 
expression + expression 
expression - expression 
expression < expression 
expression <= expression 
expression = expression 
expression >= expression 
expression > expression 
expression ~< expression 
expression ~<= expression 
expression ~= expression 
expression ~>= expression 


NN NN NNNNN DN 


expression ~> expression 
expression & expression 
expression cand expression 
expression | expression 
expression cor expression 


at aR wR at Bh ak Be Dk Bk BR Pe Pk OR Pk Pk ak PR Dk Ok 
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nit 
true 


primary 


false 
int_literal 
real_literal 
char_literal 
string _literal 
idn 


idn { constant , ... J 

primary . name 

primary [ expression } 

invocation 

type_spec $ { field ,... } 

type_spec $ [ [ expression : ] [ expression , ... h 
type_spec $ name [ C constant, ... ] ] 


force { type_spec } 
up ( expression ) 


down ( expression ) 
invocation = primary ( [ expression , ... ) 


field : ss name, ... : expression 


Reserved word: one of the identifiers appearing in bold face in the syntax. Upper and lower 
case letters are not distinguished in reserved words. 

Name, idn: a sequence of letters, digits, and underscores that begins with a letter or underscore, 
and that is not a reserved word. Upper and lower case letters are not distinguished in names and 
idns. 

Int_literal: a sequence of one or more decimal digits. 

Real_literal: a mantissa with an (optional) exponent. A mantissa is either a sequence of one or 
more decimal digits, or two sequences (one of which may be empty) joined by a period. The 
mantissa must contain at least one digit. An exponent is 'E’ or 'e’, optionally followed by ’+’ or '~’, 
followed by one or more decimal digits. An exponent is required if the mantissa does not contain a 


period. 
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Char_literal: either a printing ASCII character (octal value 40 thru 176), other than single quote 
or backslash, enclosed in single quotes, or one of the following escape characters enclosed in single 


quotes: 


escape sequence character 


\' * (single quote) 
" "(double quote) 
\\ \ (backslash) 

\n NL (newline) 

\t HT (horizontal tab) 
\p FF (newpage) 

\b BS (backspace) 

\r CR (carriage return) 
\v VT (vertical tab) 


\s28 specified by octal value (exactly three octal digits) 

The escape sequences may be written using upper case letters. 

String_literal: a sequence of zero or more character representations, enclosed in double quotes. 
A character representation is either a printing ASCII character other than double quote or 
backslash, or one of the escape sequences listed above. 

Comment: a sequence of characters that begins with a percent sign, ends with a newline 
character, and contains only printing ASCII characters and horizontal tabs in between. 

Separator: a blank character (space, vertical tab, horizontal tab, carriage return, newline, form | 
feed) or a comment. Zero or more separators may appear between any two tokens, except that at 
least one separator is required between any two adjacent non-self-terminating tokens: reserved 


words, identifiers, integer literals, and real literals. 
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Appendix II - Built-in Types and Type Generators 


The following sections describe the built-in types and the types produced by the built-in type 
generators. For each type, the objects of the type are characterized, and all operations of the type 
are defined (with the exception of the encode and decode operations, which are defined in 
Appendix III, Section 6). 

In defining an operation, arg/, arg2, etc., refer to the arguments (the objects, not the syntactic 
expressions), and res refers to the result of the operation. If execution of an operation terminates 
in an exception, we say the exception “occurs”. By convention, the order in which exceptions are 
listed in the operation type is the order in which the various conditions are checked. 

The definition of an operation consists of an interface specification and an explanation of the 
relation between arguments and results. An interface specification has the form 
name: type_spec side_effects 

restrictions 

If side_effects is null, no side-effects can occur. “PSE” (primary side-effect) indicates that the state 
of arg! may change. “SSE” (secondary side-effect) indicates that a state change may occur in some 
ob ject that is contained in an argument! Restrictions, if present, is either a standard where 
clause, or a clause of the form 

where each T; has oper_decl, 
which is an abbreviation for 

where T, has oper_decl,, 1 T, has oper_decl, 

“Arithmetic expressions and comparisons used in defining operations are to be computed over 
the domain of mathematical integers or the domain of mathematical reals; the particular domain 
will be clear from context. 
rn is 
called the i element. A tuple with n elements is called an n-tuple. We define the following 


Definitions of several of the types will involve tuples. A tuple is written <e 


functions on tuples: 


1. For operations of the built-in types, secondary side-effects occur when a subsidiary abstraction 
performs unwanted side-effects. For example, side-effects are mot expected when 
arraylT }$similar calls T$similar, but their absence cannot be guaranteed. 
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Size(<e,, ww @>) a on 

A =B w (Size(A) = Size(B)) A (Vil 1sisSize(A)a, = bJ 

<a, ..., b> We <c,...,d> = «a,.., b,¢, ..., d> 

Front(<a, ...,b,c>) = «a, ..., b>. 

Tail(<a, b, ...,c>) = <b, ..., c> , 

Tail(A) =» A and Tail®A) = TaiKTail\A) 
Occurs(A, B, ) = (3C,DM(B = CH AWD) A (Size) =i - DI 


If Occurs(A, B, i) holds, we say that A occurs in B at index i. 
Ii.1. Null 


There is one immutable ob ject of type null, denoted nil. 


equal: proctype (null, nulf returns (boo) 
similar: proctype (null, nul) returns (boo) 


Both operations always return true. 


copy: proctype (nul? returns (nul) 
Copy always returns nil. 
II.2. Bool 


There are two immutable objects of type bool, denoted true and faise. These objects 
represent logical truth values. | 


and: proctype (bool, boo! returns (boo) 
or: proctype (bool, boo) returns (boo? 
not: proctype (boo) returns (bool 


These are the standard logical operations. 


equal: proctype (bool, bool returns (bool 
similar: proctype (bool, bool returns (boo) 


These two operations return true if and only if both arguments are the same ob ject. 


copy: proctype (boo? returns (bool 
Copy simply returns its argument. 


S113 


II.3. 
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Int 


Objects of type int are immutable, and are intended to model the mathematical integers. 


However, the only restriction placed on an implementation is that some closed interval 


Cint_ Min, Int Max) be represented, with Int. Min <0 and Int_Max >0. An overflow exception 


is signalled by an operation if the result of that operation would lie outside this interval. 


add: 
sub: 
mul: 


minus: 


div: 


mod: 


power: 


proctype (int, int) returns (int) signals (overflow) 
proctype (int, int) returns (int) signals (overflow) 
proctype (int, in® returns (ind signals (overflow) 


The standard integer addition, subtraction, and multiplication operations. 


proctype (int) returns (int) signals (overflow) 


Minus returns the negative of its argument. 


proctype (int, int) returns (ind signals (zero_divide, overflow) 


Div computes the integer quotient of arg! and arg2: 
3r (0 <r < arg) vn (arg! = arg2eres + 1)) 
Zero_divide occurs if arg2 = 0. 


proctype (int, int) returns (int) signals (zero_divide, overflow) 


Mod computes the integer remainder of dividing arg! by arg2. That is, 
3g (0 < res < larga) n (arg! = arg2eq + res)) 
Zero_divide occurs if arg2 = 0. 


proctype (int, int) returns (int) signals (negative_exponent, overflow) 


This operation computes arg! raised to the arg2 power. Power(0, 0) = 1. 
Negative_exponent occurs if arg2 < 0. 


from_to_by: itertype (int, int, Int) yields (int 


from_to: 


This iterator yields, in succession, argl, arg! + arg3, arg! + 2earg3, etc., as long as the 
value to yield, x, satisfies x < arg2 when arg? >0, or arg2 <x when arg? <0. The 
iterator continually yields arg! if arg? =0. The iterator yields nothing when 
(argl > arg2) 0 (arg3 > 0) or when (arg! < arg2) n (arg? < 0). 


itertype (int, ind yields (ind 
from_to(arg!, arg2) is equivalent to from_to_by(argl/, arg2, 1). 
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parse: proctype (string) returns (int signals (bad_format, overflow) 


This operation computes the exact value corresponding to an integer literal. The 
argument must be an integer literal, with an optional leading plus or minus sign. 
Bad_format occurs if the argument is not of this form. 


unparse: proctype (int) returns (string) 


Unparse produces an integer literal such that parse(unparse(argl) = argi. Leading 
zeros are suppressed, and no leading plus sign is added for positive integers. 


It: proctype (int, int) returns (bool) 
le: proctype (int, ind returns (bool) 
ge: proctype (int, in? returns (bool) 
gt: proctype (int, int) returns (bool) 


The standard ordering relations. 
equal: proctype (int, int) returns (bool 
similar: proctype (int, int) returns (bool) 


These two operations return true if and only if both arguments are the same ob ject. 


copy: proctype (int returns (ind 
Copy simply returns its argument. 


II.4. Real 


Ob jects of type real are immutable, and are intended to model the mathematical real numbers. 
However, only a subset of 
D = [-Real_ Max, -Real_ Min} U {0} U [Real. Min, Real_Max] 
need be represented, where 0 < Real Min <1 < Real. Max. Call this subset Real. We require that 
both 0 and 1 be elements of Real. If the exact value of a real literal lies in D, then the value in 


CLU is given by a function Approx, which satisfies the following axioms: 


VreD Approx(r) € Real 

V re Real Approx(r) =r 

VreD-{0} — |tApprox(r) - 1/1] < 10!-P 
VrseD r <s— Approx(r) < Approx(s) 
VreD Approx(-r) = -Approx(r) 


The constant p is the precision of the approximation, and must be at least 7. 
We define Max width and Exp_width to be the smallest integers such that every non-zero 
element of Real can be represented in “standard” form (exactly one digit, not zero, before the 


decimal point) with no more than Max_width digits of mantissa and no more than Exp_width 


§II.4 
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digits of exponent. 


add: 
sub: 
mul: 
minus: 
div: 


power: 


i2r: 


r2i: 


trunc: 


proctype (real, real) returns (real) signals (overflow, underflow) 

proctype (real, real returns (real signals (overflow, underflow) 

proctype (real, real) returns (real) signals (overflow, underflow) 

proctype (real) returns (real - 

proctype (real, real) returns (real) signals (zero_divide, overflow, underflow) 


These operations satisfy the following axioms: 


D = (ab 20v ab < 0) > add(a, b) = Approx(a + b) 
2) add(a, b) = (1+ ea + b) lel <10!-P 

3) add(a, 0) = a 

4) add(a, b) = add(b, a) 

5) a <a’ add(a, b) < add(a’, b) 

6) = minus(a) = -a 

n sub(a, b) = add(a, -b) 

8) = mula, b) = Approx(a + b) 

9) = div(a, b) = Approx(a / b) 


In axiom 2, the value of p is the same as that used in defining Approx. Note that the 
infix and prefix expressions above are computed over the mathematical real numbers. 
The axioms only hold if no exceptions occur. An exception occurs if the result of an 
exact computation lies outside of D; overflow occurs if the magnitude exceeds 
Real Max, and underflow occurs if the magnitude is less than Real_Min. Zero_divide 
occurs if arg2 = 0. 


proctype (real, real) returns (real 

signals (zero_divide, complex_result, overflow, underflow) 
This operation computes arg! raised to the arg2 power. Zero_divide occurs if 
(arg! = 0) A (arg2 <0). Complex_result occurs if arg! <0 and arg2 is non-integral. 
Overflow and underflow occur as explained above. 
proctype (int) returns (real) signals (overflow) 
I2r returns a real number corresponding to the argument: res = Approx(argl. Overflow 
occurs if arg! lies outside the domain D. 
proctype (real) returns (int) signals (overflow) 


R2i rounds to the nearest integer, and toward zero in case of a tie: 
(\res - argil < 1/2) n res] < larga + 1/2) 
Overflow occurs if the result lies outside the domain for CLU integers. 


proctype (real) returns (int) signals (overflow) 


Trunc truncates its argument toward zero: (res - argil <1) A (lres| < |argi). Overflow 
occurs if the result lies outside the domain for CLU integers. 
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exponent: 


mantissa: 


parse: 


unparse: 


tt: 

le: 
ge: 
gt: 


equal: 
similar: 


copy: 
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proctype (real returns (int) signals (undefined) 


This operation returns the exponent that would be used in representing arg/ as a literal 
in standard form: res = max{i| largi| 2104), Undefined occurs if arg! = 0.0. 


proctype (real) returns (real) 


This operation returns the mantissa of arg! when represented in standard form: 
res = Approx(argl / 10¢XPonentargl), 
If r = 0.0 the result is 0.0. 


proctype (string) returns (real) signals (bad_format, overflow, underflow) 


This operation computes the exact value corresponding to a real or integer literal, and 
then returns the result of applying Approx to that value. The argument must be a real 
or integer literal, with an optional leading plus or minus sign. Bad_format occurs if the 
argument is not of this form. Overflow occurs if the magnitude of the exact value of 
the literal exceeds Real. Max; underflow occurs if the magnitude is less than Real_Min. 


proctype (real) returns (string) 


Unparse produces a real literal such that parse(unparse(argl)) = argl. The general form 
of the literal is: 


[-} field y_field[ esx field] 
Leading zeros in i_field and trailing zeros in f_field are suppressed. If arg/ is integral 
and within the range of CLU integers, then f_field and the exponent are not present. 
If arg! can be represented by a mantissa of no more than Max_width digits and no . 
exponent (ie., -1 < exponent(arg!) < Max_width), then the exponent is not present. 
Otherwise, the literal is in standard form, with Exp_width digits of exponent. 


proctype (real, real) returns (bool 
proctype (real, real) returns (bool) 
proctype (real, real) returns (bool 
proctype (real, real) returns (bool 


The standard ordering relations. 
proctype (real, real) returns (bool) 
proctype (real, real) returns (bool 


These two operations return true if and only if both arguments are the same ob ject. 


proctype ( real returns (real) 


Copy simply returns its argument. 
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II.6. Char 


Objects of type char are immutable, and represent characters. Every implementation must 
provide at least 128, but no more than 512, characters. Characters are numbered from 0 to some 
Char_Top, and this numbering defines the ordering for the type. The first 128 characters are the 


ASCII characters in their standard order. 


i2c: proctype (int) returns (char) signals (illegal_char) 
I2c returns the character corresponding to the argument. Itegal_char occurs if the 
argument is not in the range [0, Char..Top]. 

c2i: proctype (char) returns (ind 


This operation returns the number corresponding to the argument. 


It: proctype (char, char) returns (boo) 
le: proctype (char, char) returns (boo) 
ge: proctype (char, char) returns (bool) 
gt: proctype (char, char) returns (boo! 


The ordering relations consistent with the numbering of characters. 
equal: proctype (char, char) returns (bool) 
similar: proctype (char, char) returns (bool) 


These two operations return true if and only if the two arguments are the same ob ject. 


copy: , proctype (char) returns (char) 


Copy simply returns its argument. 
II.6. String 


Objects of type string are immutable. Each string represents a tuple of characters. The i 
character of the string is the i'* element of the tuple. There are an infinite number of strings, but 
an implementation need only support a finite number. Attempts to construct illegal strings result in 


a failure exception. 


size: proctype (string) returns (ind 


This operation simply returns the size of the tuple represented by the argument. 


empty: proctype (string) returns (bool) 


This operation returns true if and only if size(argf = 0. 
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indexs: 


indexc: 


c2s: 


concat: 


append: 


fetch: 


rest: 


substr: 


s2ac: 


ac2s: 
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proctype (string, string) returns (int 


If arg! occurs in arg2, this operation returns the least index at which arg/ occurs: 
res = minli | Occurs(argi, arg2, i)} 

Note that the result is 1 if arg/ is the 0-tuple. The result is 0 if arg! does not occur. 

proctype (char, string) returns (int) 


If <argl> occurs in arg2, the result is the least index at which <arg/> occurs: 
res = minti | Occurs(<argl>, arg2, i)} 

The result is 0 if <arg/> does not occur. 

proctype (char) returns (string) 


This operation returns the string representing the I-tuple <argl>. 


proctype (string, string) returns (string) 


Concat returns the string representing the tuple arg! Il arg2. 


proctype (string, char) returns (string) 


This operation returns the string representing the tuple arg/ i! <arg2>. 


proctype (string, int) returns (char) signals (bounds) 


Fetch returns the arg2" character of argi Bounds occurs if arg2<1 or 
arg2 > sizelargi). 


' proctype (string, int) returns (string) signals (bounds) 


The result of this operation is Tail’® (argh. Bounds occurs if arg2<1 or 
arg2 > size(argl) + 1. 


proctype (string, int, int) returns (string) signals (bounds, negative_size) 


If arg? < size(rest(argi, arg2)), the result is the string representing the tuple of size arg? 
which occurs in argi at index arg2. Otherwise, the result is rest(arg/, arg2). Bounds 
occurs if arg2 <1 or arg2 > size(argi) + 1. Negative_size occurs if arg? < 0. 


proctype (string) returns (arrayl char)) 


This operation places the characters of the argument as elements of a new array of 
characters. The low bound of the array is 1, and the size of the array is sizelargN. The 
i'* element of the array is the i* character of the string. 


proctype (array{char)) returns (string)) 


Ac2s serves as the inverse of s2ac. The result is the string with characters in the same 
order as in the argument. That is, the i character of the result is the 
(i + fowlargl - 1)" element of the argument. 
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s2sc: 


scQs: 


chars: 


equal: 


similar: 


copy: 
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proctype (string) returns (sequencelchar)) 


This operation transforms a string into a sequence of characters. The size of the 
sequence is size(argl). The i** element of the sequence is the i character of the string. 


proctype (sequence! char)) returns (string) 


Sc2s serves as the inverse of s2sc. The result is the string with characters in the same 
order as in the argument. That is, the i" character of the result is the i element of the 
argument. , 


itertype (string) yields (char) 


This iterator yields, in order, each character of the argument. 


proctype (string, string) returns (bool) 
proctype (string, string) returns (bool 
proctype (string, string) returns (boo) 
proctype (string, string) returns (boo) 


These are the usual lexicographic orderings based on the ordering for characters. The 
It operation is equivalent to the following: 


It = proc (x, y: string) returns (boo) 
size_x: int := string$size(x) 
size_y: int := string$sizely) 
min: int 
if size_x <= size_y 
then min := size_x 
else min := size_y | 
end 

for i: int In int$from_to(l, min) do 
if x{i) ~= yli) then return(xli) < yli)) end 
end 

return(size_x < size_y) 

end It 


proctype (string, string) returns (bool 
proctype (string, string) returns (bool 


These two operations return true if and only if both arguments are the same ob ject. 


proctype ( string) returns (string) 
Copy simply returns its argument. 
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II.7. Array Types 


The array type generator defines an infinite class of types. For every type T there is a type 
array(T]. Arrays are mutable objects. The state! of an ob ject of type array(T] consists of: 


a) an integer Low, called the low bound, and 
b) a tuple Elts of objects of type T, called the elements. 


We also define Size = Size(Elts), and High = Low + Size - 1. We want to think of the elements of 
Elts as being numbered from Low, so we define the array_index of the i element to be 
(i + Low - D. 

For any array, Low, High, and Size must be legal integers. Any attempts to create or modify 
an array in violation of this rule results in a failure exception. Note that for all array operations, 
if an exception other than failure occurs, the states of all array arguments are unchanged from 


those at the time of invocation. 


create: proctype (int) returns (array{T)) 


This operation returns a new array for which Low is arg! and Elts is the 0-tuple. 


new: proctype () returns (array(T]) 


This is equivatent to create(1). 


predict: proctype (int, int) returns (array(T)) 


Predict is essentially the same as create(argl, in that it returns a new array for which 
Low is argi and Elts is the 0-tuple. However, if arg2 is greater than (less than) 0, it is 
assumed that at least |arg2| addh’s (addl's) will be performed on the array. These 
subsequent operations may execute somewhat faster. 


low: proctype (array[T)) returns (int) 
high: proctype (array{T]) returns (ind 
size: proctype (array[T)) returns (ind 


These operations return Low, High, and Size, respectively. 


empty: proctype (array([T])) returns (bool) 


This operation returns true if and only if Size = 0. 


1. For an array A, we should properly write Low,, etc., to refer to the state of that particular 
ob ject, but subscripts will be dropped when the association seems clear. 
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set_low: 


trim: 


fill: 


fill_copy: 


fetch: 


bottom: 
top: 


store: 
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proctype (array{T), int) PSE 


Set_low makes Low equal to arg2. 


proctype (array{T], int, int signals (bounds, negative_size) PSE 


This operation makes Low equal to arg2, and makes Elts equal to the tuple of size 
mintarg3, High’ - arg2 + 1} which occurs in Elts’ at index arg2 - Low’ + 1! That is, 
every element with array_index less than arg2, or greater than or equal to arg2 + arg?, 
is removed. Bounds occurs if arg2 < Low’ or arg2 > High’ + 1. Negative_size occurs if 
arg? <0. Note that this operation is somewhat like string$substr. 


proctype (int, int, T) returns (array{T)) signals (negative_size) 


Fill creates a new array for which Low is arg! and Elts is an arg2-tuple in which every 
element is arg?. Negative_size occurs if arg2 < 0. 


proctype (int, int, T) returns (array(T)) signals (negative_size) SSE 
where T has copy: proctype (T) returns (T) 


This operation is equivalent to the following: 


fill_copy = proc (nlow, nsize: int, elt: T) returns (at) signals (negative_size) 
where T has copy: proctype (T) returns (T) 

at = array{T) 
tf nsize < 0 then signal negative_size end 
xX: at := at$predict(nlow, nsize) 
for i: int in int$from_to(l, nsize) do 

at$addh(x, T$copyleit)) 

end 
return(x) 
end fill_copy 


proctype (array(T], ind returns (T) signals (bounds) 

Fetch returns the element of arg! with array_index arg2. Bounds occurs if arg2 < Low 
or arg2 > High. 

proctype (array{T)) returns (T) signals (bounds) 

proctype (array(T]) returns (T) signals (bounds) 

These operations return the elements with Harta) NCEA: Low and me” respectively. 
Bounds occurs if Size = 0. 

proctype (array{T], int, T) signals (bounds) PSE 


Store makes Elts a new tuple which differs from the old in that arg? is the element 
with array_index arg2. Bounds occurs if arg2 < Low or arg2 > High. 


1. Elts’, High’, etc. refer to the state just prior to invoking the operation. 
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addh: 


addi: 


remh: 


rem: 


elements: 


indexes: 


equal: 
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proctype (array{T], T) PSE 


This operation makes Elts the new tuple Elts’  <arg2>. 


proctype (array{T), T) PSE 


This operation makes Low equal to Low’ - 1, and makes Elts the tuple <arg2> il Elts’. 
Decrementing Low keeps the array_indexes of the previous elements the same. 


proctype (array(T]) returns (T) signals (bounds) PSE 


Remh makes Eilts the tuple Front(Elts’), and returns the deleted element. Bounds occurs 
if Size’ = 0. 


proctype (array{T]) returns (T) signals (bounds) PSE 


Rem! makes Low equal to Low’ + 1, makes Elts the tuple TaiKElts), and returns the 
deleted element. Incrementing Low keeps the array_indexes of the remaining elements 
the same. Bounds occurs if Size’ = 0. 


itertype (array(T]) yields (T) 
This iterator is equivalent to the following: 


elements = iter (x: at) yields (T) 
at = array(T) 
for i: int In int$from_tolat$tow(x), at$high(x)) do 
yleld& xi) 
end 
end elements | 


‘itertype (array(T)) yields (ind 


This iterator is equivalent to int$from_to(Low’, High). 


proctype (array{T], array{T)) returns (booD . 
Equal returns true if and only if both arguments are the same ob ject. 
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similar: proctype (array(T), array({T)) returns (bool) SSE 
where T has similar: proctype (T, T) returns (booD 


This operation is equivalent to the following: 


similar = proc (x, y: at) returns (boo? 
where T has similar: proctype (T, T) returns (boo) 
at = array(T] 
if atSlow(x) ~= at$low(y) cor at$size(x) ~= at$sizely) 
then return(false) 
end 
for i: int In at$indexes(x) do 
if ~T$similar(xli], yli}) then returnifaise) end 
end 
return true) 
end similar 


similar]: proctype (array(T), array(T)) returns (booD SSE 
where T has equal: proctype (T, T) returns (bool 
Similar] works in the same way as similar, except that T$equal is used instead of 
T$similar. 
copyl: proctype (array{T)) returns (array{T)) 
Copyl creates a new array with the same state as the argument. 
copy: proctype (array{T)) returns (array(T)) SSE _ 
where T has copy: proctype (T) returns (T) 
This operation is equivalent to the following: 


copy = proc (x: at) returns (at) where T has copy: proctype (T) returns (T) 
at = arraylT] 
X := at$copyl(x) 
for i: int in at$indexes(x) do 
xLi) := T$copy(xti)) 
end 
return(x) 
end copy 


II.8. Sequence Types 


The sequence type generator defines an infinite class of types. For every type T there is a 
type sequence(T]. An object of type sequencelT) consists of a tuple, Elts, of ob jects of type T, 
called the elements of the sequence. Sequences are immutable objects: a particular sequence always 
represents exactly the same tuple of objects. However, if the objects in the tuple are mutable, then 


the state of those ob jects may change. 


2 
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For convenience, we define Size = Size(Elts). The elements of a sequence are numbered from 1 


to Size. For any sequence, Size must be a legal integer; any attempt to create a sequence that 


violates this rule results in a failure exception. 


new: 


size: 


empty: 


subseq: 


Fill: 


fill_copy: 


fetch: 


proctype () returns (sequence(T)) 


This operation returns the empty sequence. 


proctype (sequence(T)) returns (ind 


This operation returns Size. 


proctype (sequence(T])) returns (boo) 
Empty returns true if and only if Size = 0. 
proctype (sequence[T], Int, int) returns (sequencel T)) 

signals (bounds, negative_size) 
If arg? < Size - arg2 +1 then the result is the tuple of size arg? occurring in arg! 
starting at index arg2. Otherwise, the result is the tuple Tail”®*"(argN. Bounds occurs 
if arg2 < 1 or arg2 > Size + 1. Negative_size occurs if arg? < 0. 
proctype (int, T) returns (sequence(T}) signals (negative_size) 
Fill returns the sequence for which Elts is the ia ad in which every element is ate? 
Negative_size occurs if argl < 0. 
proctype (int, T) returns (sequencelT]) signals (negative_size) SSE 
This operation is equivalent to the following: 


_ fill_copy = proc (nsize: int, elt: T) returns (qt) signals (negative_size) 


where T has copy: proctype (T) returns (T) 

qt = sequencelT] 
If nsize < 0 then signal negative_size end 
X: qt := qt$new() 
for i: int In int$from_to(l, nsize) do 

x :& qtSaddh(x, T$copylel)) 

end 
return(x) 
end fill_copy 


proctype (sequence!T], int returns (T) signals (bounds) 
Fetch returns the arg2™ element of arg!. Bounds occurs if arg2 < 1 or arg2 > Size. 
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bottom: 
top: 


replace: 


addh: 


addi: 


remh: 


rem: 


e2s: 


concat: 


a2s: 


$2a: 


elements: 


indexes: 
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proctype (sequencelT]) returns (T) signals (bounds) 
proctype (sequence(T)) returns (T) signals (bounds) 


These operations return the first and last elements of argi, respectively. Bounds occurs 
if Size = 0. 

proctype (sequence[T), int, T) returns (sequence{T)) signals (bounds) 

This operation returns a new sequence whose arg2"" element is arg?, but which is 
otherwise the same as arg/. Bounds occurs if arg2 < 1 or arg2 > Size. 

proctype (sequencelT]), T) returns (sequencelT)) 


Addh returns the sequence representing the tuple Elts i <arg2>. 


proctype (sequence(T], T) returns (sequence{T]) 
Addl returns the sequence representing the tuple <arg2> Il Elts. 


proctype (sequencelT)) returns (sequencelT)) signals (bounds) 

Remh returns the sequence representing the tuple Front(Elts). Bounds occurs if 
Size = 0. 

proctype (sequence(T)) returns (sequencelT)) signals (bounds) 


Reml returns the sequence representing the tuple TaiKEIts). Bounds occurs if Size = 0. 


proctype (T) returns ( sequence T)) 


This operation returns the sequence representing the singleton tuple <arg/>. 


proctype (sequencelT), sequence[T]) returns (sequence! T)) 


Concat returns the sequence representing the tuple arg/ Il arg2. 


proctype (array(T)) returns (sequencelT)) 
This operation returns the tuple corresponding to the elements part of the state of argl. 


proctype (sequence! T)) returns (array{T)) . 
This operation returns a new array with low bound | and with Elts as the elements part 
of the array state. 

itertype (sequence(T)) yields (T) 

This iterator yields, in order, each element of Elts. 


itertype (sequencelT)) yields (int 


This iterator is equivalent to int$from_to(l, Size). 
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equal: proctype (sequence! T), sequence(T)) returns (bood SSE 
where T has equal: proctype (T, T) returns (bood 


Equal is equivalent to the following: 


equal = proc (x, y: qt) returns (boo? 
where T has similar: proctype (T, T) returns (bood 
qt = sequencal T] 
If qt$size(x) ~= qt$sizely) then return false) end 
for i: int in qtSindexes(x) do 
if x{i)] ~= yfi) then return faise) end 
end ' 
return true) 
end equal 


similar: proctype (sequence!T), sequence(T)) returns (boo? SSE 
where T has similar: proctype (T, T) returns (boo) | 
Similar works in the same way as equal, except that TSsimilar is used instead of 
TS$equal. 
copy: proctype (sequenceT)) returns (sequencelT)) | SSE 
where T has copy: proctype (T) returns (T) 
This operation is equivalent to the following: 


copy = proc (x: gt) returns (qt) where T has copy: proctype (T) returns (T) 
qt = sequence! T) 
y: qt := qtSnewl) 
for e: T in qtSelements(x) do 
y := q@Saddhly, TScopyle)) 
' end 


return(y) 
end copy 


II.8. Record Types 


The record type generator defines an infinite class of types. For every tuple of name/type 
pairs <(N,, T,), ....(N,, T,)>, where all the names are distinct, in lower case, and in lexicographic 
order, there is a type recordiN :T,, ....N,:T,]. (However the user may write this type with the 
pairs permuted, and may use upper case letters in names.) Records are mutable objects. The state 
of a record of type record(N,,:T,,, .... N,:T,] is an n-tupte; the i® element of the tuple is of type T, 
The i™ element is also called the N.-component. 


+ if 


S119 


create: 


get_N; : 
set_N: : 


equal: 


similar: 


similarl: 


copyl: 
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proctype (T,. .. T,) returns (recordiN pl pon N;T,)) 

This operation returns a new record with the tuple <argi, ..., argN> as its state. This 

operation is not available to the user; its use is implicit in the record constructor (see 

Section 10.6). 

proctype (recordiN |:T ,, .., N:T J) returns (T) 

This operation returns the N-component of the argument. There is a get_N; operation 

for each N.. 

proctype (recordiN pl pes NT, 7) | PSE 

This operation makes the state of arg! a new tuple which differs from the old in that 

the N,-component is arg2. There is a set_N; operation for each N.. 

proctype (record{N eke N.T,), recordN aT yy in N,:T,)) returns (boo) 

Equal returns true if and only if both arguments are the same ob ject. 

proctype (recordiN |:T,, .... NT), recordN |:T,, .... N:T,)) returns (bool SSE 
where each T, has similar: proctype (T, T) returns (boo) 


Corresponding components of arg! and arg2 are compared in (lexicographic) order, 
using T$similar for the N-components. (The N-component of arg! becomes the first 
argument.) If a comparison results in false, the result of the operation is false, and no 
further comparisons are made. If all comparisons return true, the result is true. 


proctype (recordN :T,, ..., N.:T,], recordiN iT ys N,;:T,,)) returns (boo) SSE 
where each T, has equal: proctype (T,, T) returns (boo) 

Similar! works in the same way as similar, except that TSequal is used instead of 

T $similar. 

proctype (recordN :T,,, kes N,:T) returns (recordiN ,:T,,, dog NT) 


Copy! returns a new record with the same state as the argument. 
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copy: 
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proctype (recordN ,:T ,, .... N.:T,)) returns (recordiN :T ,, -. N TD SSE 
where each T, has copy: proctype (T) returns (T) 


This operation is equivalent to the following (note that the N, are in lexicographic 
order): 


copy = proc (x: rt) returns (rt) 
where T, has copy: proctype (T)) returns (T), 


T, has copy: proctype (T,) returns (T,) 
t= record N |:T ,, pen NJTJ : 
X := rt$copyl(x) 
x.N, := T,Scopy{x.N) 


x.N, := T,Scopy(x.N) 
return(x) 
end copy 


11.10. Structure Types 


The struct type generator defines an infinite class of types. For every tuple of name/type 
pairs <(N,, T,), -. (N,, T)>, where all the names are distinct, in lower case, and in lexicographic 
order, there is a type structiN,:T,, ....N-:TJ. (However the user may write this type with the 
pairs permuted, and may use upper case letters in names.) Structures are immutable ob jects. A 
structure of type structiN,:T,, .... N,:T,] is an n-tuple; the i® element of the tuple is of type T, 
The i'* element is also called the N.-component. 


create: 


get; : 


replace_N; : proctype (structiN :T,, .... N:T,J, T) returns (structN :T,, —, NT. » 


s2r: 


proctype (T,, ..., T,) returns (structN,:T,, ., NT) 

This operation returns the structure representing the tuple <argl,...argN>. This 
Operation is not available to the user; its use is implicit in the structure constructor (see 
Section 10.6). 

proctype (structiN ,:T,, ... NT.) returns (T) 


This operation returns the N-component of the argument. There is a get_N; operation 
for each N.. 


This operation returns the tuple corresponding to erg! with its N.-component reptaced 
by arg2. There is a replace_N; operation for each N,. 


proctype (structiN |:T.,, .... N,:T,]) returns (recordN :T ,, — N,:T ) 
S2r returns a new record whose initial state is the tuple represented by the argument. 
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r2s: 


equal: 


similar: 


copy: 
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proctype (recordN |:T,, .... N.:T,]) returns (structiN,:T,,, .... N.:T)) 


R2s returns the structure representing the tuple that is the current state of the argument. 


proctype (struct(N |:T,, NT), structiN :T,, xe NT) returns (bool) SSE 
where each T; has equal: proctype (T, T) returns (boo) 

Corresponding components of arg! and arg2 are compared in (lexicographic) order, 

using T$equal for the N-components. (The N-component of arg! becomes the first 


argument.) If a comparison results in false, the result of the operation is false, and no 
further comparisons are made. If all comparisons return true, the result is true. 


proctype (structiN :T,, » NT, structiN :T,, ak N,:T,)) returns (boo) SSE 
where each T, has similar: proctype (T, T) returns (boo) 


Similar works in the same way as equal, except that T$simitar is used instead of 
T $equal. : 


proctype (struct{N ,:T, NT.) returns (structiN .:T,,, .... NT) SSE 
where each T, has copy: proctype (T) returns (T)) 


This operation is equivalent to the following (note that the N. are in lexicographic 
order): 


copy = proc (x: st) returns (st) 
where T, has copy: proctype (T,) returns (T ,), 


T, has copy: proctype (T,) returns (T) 
st = structiN|:T,, ... NT] 
return(st${N |: T|S$copy(x.N)), 


N,: T scopylx.N))) 
end copy 


II.11. Oneof Types 


The oneof type generator defines an infinite class of types. For every tuple of name/type 


pairs <(N,,T,),...(N,,T,)>, where all of the names are distinct, in lower case, and in 


lexicographic order, there is a type oneof{N,:T,, ....N.:T,J. (However the user may write this type 


with the pairs permuted, and may use upper case letters in names.) Oneofs are immutable ob jects. 


Each oneof represents a name/object pair (NX), where X is of type T;, For each object X of 


type T; there is a oneof ‘for the pair (N, X). N, is called the tag of the oneof, and X is called the 


value. 


Ns 


make_N; : 


is_N; : 


value_N; : 


o2v: 


v2o: 


equal: 


similar: 
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proctype (T) returns (oneof{N |:T,, ‘acs NT) 

This operation returns the oneof for the pair (N, argh. There is a make_N; operation 
for each N. 

proctype (oneoffN |:T ,, .... N.:T)) returns (boob 

This operation returns true if and only if the tag of the argument is N. There is an 
is_N; operation for each N. 

proctype (oneoff{N |:T,, .... N.:T,)}) returns (T) signals (wrong_tag) 


If the argument has tag N, the resuk is the value component of the argument. 
Wrong_tag occurs if the tag is other than N, There is a value_N, operation for each 
N ar 


proctype (oneof{N |:T ,, .... N:T,]) returns (varientiN |:T ,, NT) 

This operation returns a new variant with an initial state that has the same tag and 

value as the argument. 

proctype (variantiN |:T,, - NT) returns (oneoffN :T ,, ... NT) 

This operation returns the oneof with the same tag and value as the current state of the 

argument. 

proctype (oneofiN |:T,, ...,N,:T,J, oneoffN :T,,, .... NT) returns (bood SSE 
where each T, has equal: proctype (T, T) returns (boo) : 

If arg! and arg2 have different tags, the resu is faise. If both tags are N, the result 

is that of invoking T Sequal with the two value components. 

proctype (oneofiN |:T,, .... N.:T,), oneoftN :T ,, NT) returns (boo) SSE 

where each T, has similar: proctype (T, T) returns (boo? 
If arg! and arg2 have different tags, the resuk is faise. If both tags are N, the resuk 
is that of invoking T$similar with the two value components. 


proctype (oneoffN |:T.,, .... N:T,}) returns (oneoftN :T,, -, N.:T_}) SSE 


where each T; has copy: proctype (T) returns (T) 


If arg! represents the pair (N, X), then the result is the oneof for the pair 
(N, TScopy(X)). 
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II.12. Variant Types 


The variant type generator defines an infinite class of types. For every tuple of name/type 
pairs <(N,, T,),...(N,,T,)>, where all of the names are distinct, in lower case, and in 
lexicographic order, there is a type variantiN :T,,..,N:1 J. (However the user may write this 
type with the pairs permuted, and may use upper case letters in names.) Variants are mutable 
objects. The state of a variant consists of a name/ob ject pair (N, X), where X is of type T;. For 
each object X of type T; there is a state (N, X). N, is called the current tag of the variant, and X 


is called the current value. 


make_N: : proctype (T) returns (variantiN :T,, aah N,:T) 
This operation returns a new variant whose initial state is the pair (N, argl. There is 
a make_N, operation for each N.. , 

change_N: : proctype (variantiN :T,, an N,:T), T) PSE 
This operation changes the state of arg/ to be the pair (N, arg2). There is a change_N, 
operation for each N.. 

is_N; : proctype (variant{N pT ye N,;T,)) returns (bool 
This operation returns true if and only if the current tag of the argument is N.. There 
is an is_N; operation for each N, = 

value_N; : proctype (variantN,:T,, sis) N,:T) returns (T) signals (wrong_tag) 
If the current tag of the argument is N, then the current value component is returned. 
Wrong_tag occurs if the current tag is other than N, There is a value_N; operation for 
each N. 

equal: proctype (variantiN |:T,, .... NT J, variantN ::T,, poe N,:T,)) returns (boo) 
This operation returns true if and only if arg! and arg2 are the same ob ject. 

similar: proctype (variantiN :T,, ... NT], variantiN |:T,, .. NT) returns (boo) SSE 

where each T; has similar: proctype (T;, T) returns (boo) 

If argl and arg2 have different tags, the result is false. If both tags are N,, the result 
is that of invoking T$similar with the two value components. 

similarl: proctype (variantiN :T,, ...N,:T,], variant{N ,:T,, eats N,:T,)) returns (boo) SSE 

where each T; has equal: proctype (T,, T) returns (boo) 


If arg! and arg2 have different tags, the result is false. If both tags are N,, the resuit 
is that of invoking T$equal with the two value components. 
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copy: proctype (variantiN pT pos N,:T,)) returns (variantiN :T,, Za N,:T SSE 
where each T, has copy: proctype (T) returns (T) 


If the current state of the argument is (N, X), then the result is a new variant whose 
initial state is (N., T.$copy(X)). 
copyl: proctype (variantiN |:T ,, .... N,:T,)) returns (variantiN :T.,, .... N,:T,)) 


If the current state of the argument is (N,, X), then the resuk is a new variant whose 
initial state is also (N, X). 


11.13. Procedure and Iterator Types 


Let A, R, L,, ..., L, be ordered lists of types, and let N,, .... N, be distinct names in lower case 
and in lexicographic order. Then there is a type 
proctype (A) returns (R) signals (N (L,), ..., N(L)) 
and a type 
itertype (A) ylelds (R) signals (N(L)), sad N,(L)). 
(The user may permute the N{L)’s, and may use upper case letters in names. If R is empty then 
“returns (R)” is not written, “(L)" is not written if L; is empty, and “signats (...)" is not written if 
n= 0.) 
The create operations are not available to the user; routines are created by compiling modules. - 
Let T be a procedure (or iterator) type in the following. 
equal: proctype (T, T) returns (boo? 
similar: proctype (T, T) returns (bool 
These operations return true if and only if both arguments are the same 
implementation of the same abstraction, with the same parameters. 
copy: proctype (T) returns (T) 
Copy simply returns its argument. 


II.14. Any 


The type any is the union of all types. There are no operations for the type any. Thus, for 
example, no arrayl any)$copy operation exists. 
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Appendix III - Input/Output 


This appendix describes a set of standard “library” data types and procedures for CLU, 
provided primarily to support 1/O. We do not consider this facility to be part of the language 
proper, but felt the need for a set of commonly-used functions that have some meaning on most 
systems. This facility is minimal because we wished it to be general, i.e, to be implementable, at 
least in large part, under almost any operating system. The facility also provides a f ramework in 
which some other operations that are not always available can be expressed. 

Some thought was given to portability of programs, and possibly even data, but we expect that 
programs dealing with all but the simplest I/O will have to be written very carefully to be portable, 
and might not be portable no matter how careful one is. 


The following additional types are described: 


Stream - provides access to text files 
istream - provides access to image files 
filename - a naming scheme for files 
date - calendar date and time 


No type “file” exists, as will be explained. 
III.1. Files 


Our notion of file is a general one that includes not only storage files (disk files), but also 
terminals and other devices (e.g. tape drives). Each file will in general support only a subset of the 
operations described here. 

There are two basic kinds of files, text files and image files. The two kinds of files may be 
incompatible. However, on any particular system, it may not be possible to determine what kind a 
given file is. 

A text file consists of a sequence of characters, and is divided into lines terminated by newline 
(\n') characters. A non-empty last line might not be terminated. By convention, the start of a new 
page is indicated by placing a newpage (\p) character at the beginning of the first line of that 
page. 

A text file will be stored in the (most appropriate) standard text file format of the local 


Operating system. As a result, certain control characters (e.g. NUL, CR, FF, “C, ~Z) may be 


ignored when written. In addition, a system may limit the maximum length of lines and may add 
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(remove) trailing spaces to (from) lines. 

Image files are provided to allow more efficient storage of information than is provided by 
text files. Unlike text files, there is no need for image files to be compatible with any local file 
format; thus, image files can be defined more precisely than text files. 

An image file consists of a sequence of encoded objects. Objects are written and read using 
encode and decode operations of their types. (These in turn will call encode and decode on their 
components until basic types are reached.) The objects stored in an image file are not tagged by 
the system according to their types. Thus, if a file is written by performing a specific sequence of 
encode operations, then it must be read back using the corresponding sequence of decode operations 


to be meaningful. 
III.2. File Names 


File names are immutable objects used to name files. The system file name format is viewed 
as consisting of four string components: 


directory - specifies a file directory or device 

name - the primary name of the file (e.g. “thesis” 

suffix - a name normally indicating the type of. file (e.g. “clu” for a 
CLU source file) 

other - all other components of the system file name form 


The directory and other components: may have internal syntax. The name and suffix should be 
short identifiers. (For example, in the TOPS-20 file name “ps:<cluser>ref.tpt.3", the directory is 
“ps:<cluser>", the name is “ref”, the suffix is “Ipt", and the other is “3°. In the UNIX path name 
“/usr/snyder/doc/refman.r”, the directory is "/usr/snyder/doc”, the name is “refman”, the suffix is 
“r", and there is no other. . 

A null component has the following interpretation: 


directory - denotes the current "working" directory. (For example, the 
“connected directory” on TOPS-20 and the “current directory” 
on UNIX. See also Section 8 of this appendix.) 

name - may be illegal, have a unique interpretation, or be ignored. 
(For example, on TOPS-20, a null name is illegal for most 
directories, but for some devices, the name is ignored.) 

suffix - may be illegal, have a unique interpretation, or be ignored. 
(For example, on TOPS-20, a null suffix is legal, as in 
“<rws>foo™.) 
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other - should imply a reasonable default. 


The operations on file names are: 


create: 


get_dir: 
get_name: 
get_suf fix: 
get_other: 


parse: 


unparse: 


make_output: 


proctype (string, string, sl string) returns (file name) 
signals (bad_format) 


This operation creates a file name from its components. Argl is the directory part, 
arg2 is the name part, arg? is the suffix part, and arg¢ is the other part for the new 
filename. In the process of creating a file name, the string arguments may be 
transformed, e.g. by truncation or case-conversion. . 


proctype (file name) returns (string) 
proctype (file_name) returns (string) 
proctype (file_name) returns (string) 
proctype (filename) returns (string) 


These operations return string forms of the components of a file name. If the file 
name was created using the create operation, then the strings returned may be 
different than those given as arguments to create, e.g., they may be truncated or 
case-converted. 


proctype (string) returns (file_ name) signats (bad_format) 


This operation creates a file name given a string in the system standard file name 
syntax. 


' proctype (filename) returns (string) 


This operation transforms a file name into the system standard file name syntax. 
We require that 

parse(unparse(fn)) = fn 

create(fn.dir, fn.name, fn.suffix, fn.other) = fn 
for all file names fn. One implication of this rule is that there can be no file name 
that can be created by create but not by parse; if a system does have file names that 
have no string representation in the system standard file name syntax, then create 
must reject those file names as having a bad format. Alternatively, the file name 
syntax must be extended so that it can express all possible file names. 


proctype (file_name, string) returns (filename) signals (bad_format) 


This operation is used by programs that take input from a file and write new files 
whose names are based on the input file name. The operation transforms the file 
name into one that is suitable for an output file. The transformation is done as 
follows: (1) the suffix is set to the given suffix (arg2); (2) if the old directory is not 
suitable for writing, then it is set to null; (3) the name, if null and meaningless, is set 
to “output”. (Examples of directories that may not be suitable for writing are 
directories that involve transferring files over a slow network.) 
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make_temp: proctype (string, string, string) returns (f ile_name) signals (bad_format) 


This operation creates a file name appropriate for a temporary file, using the given 
preferred directory name (arg/), program name (arg2), and file identifier (arg3). To 
be useful, both the program name and the file identifier should be short and 
alphabetic. The returned file name, when used as an argument to stream8open or 
istream$open to open a new file for writing, is guaranteed to create a new file, and 
will not overwrite an existing file. Further file name references to the created file 
should be made using the name returned by the stream or istream gefname 
operation. 
equal: proctype (file_name, file_name) returns (bool) 


Returns true if and only if the two filenames will unparse to equal strings. 


similar: proctype (file_name, file name) returns (boo) 


The same as the equal operation. 


copy: proctype (filename) returns (file_name) 


Copy simply returns its argument. 
III.3. A File Type? 


Although files are the basic information-containing objects in this package, we do not 
recommend that a file type be introduced. The reason for this recommendation is that few systems — 
provide an adequate representation for files. 

On many systems, the most reliable representation of a file (accessible to the user) is a channel 
(stream) to that file. However, this representation is inappropriate for a CLU file type, since 
Possession of a channel to a file often implies locking that file. | 

Another possible representation is a file name. However, file names are one level indirect from 
files, via the file directory. As a result, the relationship of a file name to a file object is 
time-varying. Using file names as a representation for files would imply that all file operations 
could signal non_existent_file. 

Therefore, operations related to file ob jects are performed by two stream clusters, stream and 
istream, and operations related to the directory system are performed by procedures. 

Note that two opens for read with the same file name might return streams to two different 
files. We cannot guarantee anything about what may happen to a file after a program obtains a 


stream to it. 
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III.4. Streams 


Streams provide the means to read and write text files, and to perform some other operations 
on file ob jects. The operations allowed on any particular stream depend upon the access mode. In 
addition, certain operations may be null in some implementations. 

When an operation cannot be performed, because of an incorrect access mode, because of 
implementation limitations, or because of properties of an individual file or device, then the 
operation will signal not_ possible (unless the description of the operation explicitly says that the 
invocation will be ignored). 

The PSE and SSE indicators used in the previous appendix will not be used here; in many 


cases the exact form (and time) of change depends on the particular operating system. 


open: proctype (file_name, string) returns (stream) signals (not_possible(string)) 


The possible access modes (arg2) are “read”, “write”, and “append”. If arg2 is not 
one of these strings, not_possible("bad access mode") is signalled. In those cases 
where the system is able to detect that the specified pre-existing file is not a text file, 
not_possible(“wrong file type") is signalled. 


If the mode is “read”, then the named file must exist. If the file exists, a stream is 
returned upon which input operations can be performed. 


If the mode is “write”, a new file is created or an old file is rewritten. A stream is: 
returned upon which output operations can be performed. 


If the mode is “append”, then if the named file does not exist, one is created. A 
stream is returned, positioned at the end of the file, upon which output operations 
can be performed. Append mode to storage files should guarantee exclusive access 
to the file, if possible. 


primary_input: proctype () returns (stream) 
This operation returns the “primary” input stream, suitable for reading. This is 
usually a stream to the user’s terminal, but may be set by the operating system. 
primary_output: proctype () returns (stream) 
This operation returns the “primary” output stream, suitable for writing. This is 
usually a stream to the user's terminal, but may be set by the operating system. 
error_output: proctype () returns (stream) 


This operation returns the “primary” output stream for error messages, suitable for 
writing. This is usually a stream to the user’s terminal, but may be set by the 
operating system. 
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can_read: 


can_write: 


g etc: 


peekc: 


empty: 


pute: 


putc_image: 


getc_image: 


get_lineno: 
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proctype (stream) returns (bool) 


Can_read returns true if input operations appear possible on the stream. 


proctype (stream) returns (boo?) 


Can_write returns true if output operations appear possible on the stream. 


proctype (stream) returns (char) signals (end_of _file, not_possible(string)) 


This input operation removes the next character from the stream and returns it. 


proctype (stream) returns (char) signals (end_of_file, not_possible( string)) 


This input operation is like getc, except that the character is not removed from the 
stream. 


proctype (stream) returns (boo!) signals (not_possible(string)) 


This input operation returns true if and only if there are no more characters in the 
stream. It is equivalent to a call of peekc, where true is returned if peekc returns a 
character and false is returned if peekc signals end_of_file. Thus in the case of 
terminals, for example, this operation may wait until additional characters have been 
typed by the user. 


proctype (stream, char) signals (not_possible(string)) 


This output operation appends the given character to the stream. Writing a newline 
indicates the end of the current line. 


proctype (stream, char) signals (not_possible(string)) 


This output operation is like putc, except that an arbitrary character may be written 
and the character is not interpreted by the CLU I/O system. (For example, the ITS 
XGP program expects a text file containing certain escape sequences. An escape 
sequence consists of a special character followed by a fixed number of arbitrary 
characters. These characters could be the same as an end-of-line mark, but they are 
recognized as data by their context. On a record-oriented system, such characters 
would be part of the data. In either case, writing a newline in image mode would 
not be interpreted by the CLU system as indicating an end-of-line.) 


proctype (stream) returns (char) signals (end_of_file, not_possible(string)) 


This input operation is provided to read escape sequences in text files, as might be 
written using putc_image. Using this operation inhibits the recognition of 
end-of-line marks, where used. 


proctype (stream) returns (int) signals (end_of _file, not_possible(string)) 


This input operation returns the line number of the current (being or about to be 
read) line. If the system maintains explicit line numbers in the file, said line 
numbers are returned. Otherwise, lines are implicitly numbered, starting with 1. 
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set_lineno: 


reset: 


flush: 
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proctype (stream, int) signals (not_possible(string)) 

If the system maintains explicit line numbers in the file, this output operation sets 
the line number of the next (not yet started) line. Otherwise, it is ignored. 

proctype (stream) signals (not_possible(string)) 

This operation resets the stream so that the next input or output operation will read 
or write the first character in the file. The line number is reset to its initial value. 
proctype (stream) 


Any buffered output is written to the file, if possible. Otherwise, there is no effect. 
This operation should be used for streams that record the progress of a program. It 
can be used to maximize the amount of recorded status visible to the user or 
available in case the program dies. 


get_line_length: proctype (stream) returns (int) signals (no_limit) 


If the file or device to which the stream is attached has a natural maximum line 
length, then that length is returned. Otherwise, no_limit is signalled. The line 
length does not include newline characters. 


get_page_length: proctype (stream) returns (int) signals (no_limit) 


get_date: 


set_date: 


get_name: 


close: 


If the device to which the stream is attached has a natural maximum page length, 
then that length is returned. Otherwise, no_jimit is signalled. Storage files will 
generally not have page lengths. 

proctype (stream) returns (date) signals (not_possible(string)) 

This operation returns the date of the last modification of the corresponding storage 
file. 

proctype (stream, date) signals (not_possible(string)) 


This operation sets the modification date of the corresponding storage file. (The 
modification date is set automatically when a file is opened in “write” or “append” 
mode.) 


proctype (stream) returns (file name) signals (not_possibie(string)) 


This operation returns the name of the corresponding file. It may be different than 
the name used to open the file, in that defaults have been resolved and link 
indirections have been followed. 


proctype (stream) 


This operation terminates 1/O and removes the association between the stream and 
the file. Further use of operations that signal not_possible will signal not_possible. 
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is_closed: 


is_terminal: 


getl: 


putl: 


gets: 


puts: 


putzero: 


putleft: 


putright: 


putspace: 
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proctype (stream) returns (boo) 


This operation returns true iff the stream is closed. 


proctype (stream) returns (bool) 

This operation returns true iff the stream is attached to an interactive terminal (see 
below). 

proctype (stream) returns (string) signals (end_of _file, not_possible(string)) 


This input operation reads and returns (the remainder of) the current input line and 
reads but does not return the terminating newline (if any). This operation signals 
end_of _file only if there were no characters and end-of-file was detected. 
proctype (stream, string) signals (not_possible(string)) 
This output operation writes the characters of the string onto the stream, followed by 
a newline. . 
Proctype (stream, string) returns (string) 

signals (end_of_file, not_possible(string)) 
This input operation reads characters until a terminating character (one in arg2) or 
end-of-file is seen. The characters up to the terminator are returned; the terminator 
(if any) is left in the stream. This operation signals end_of_file only if there were 
no characters and end-of-file was detected. 
proctype (stream, string) signals (not_possible(string)) 
This output operation simply writes the characters in the string using putc. 
Naturally it may be somewhat more efficient than doing a series of individual putc’s. 
proctype (stream, string, int) signals (negative_field_width, not_possible(string)) 
Output the string. However, if the length of the string is less than the field width 
(arg3), then also output the appropriate number of extra zeros before the first digit 
or '.” in the string (or at the end, if no such characters). 
proctype (stream, string, int) signals (negative_field_width, not_possible(string)) 
Output the string. However, if the length of the string is less than arg3, then also 
output the appropriate number of extra spaces after the string. 
proctype (stream, string, int) signals (negative_field_width, not_possible( string)) 
Output the string. However, if the length of the string is less than arg3, then also 
output the appropriate number of extra spaces before the string. 
proctype (stream, Int) signals (negative_field_width, not_possible(string)) 


This operation outputs arg2 spaces. 


§Itl.4 Streams 129 


equal: proctype (stream, stream) returns (boo!) 


Returns true if and only if both arguments are the same stream. 


similar: proctype (stream, stream) returns (boo!) 


Returns true if and only both arguments are the same stream. 


copy: Proctype (stream) returns (stream) 


Returns its argument. 
III.6. String I/O 


It is occasionally useful to be able to construct a stream that, rather than being connected to a 
file, instead simply collects the output text into a string. Conversely, it is occasionally useful to be 
able to take a string and convert it into a stream so that it can be given to a procedure that expects 


a stream. The following stream operations allow these functions to be performed: 


Create_input: proctype (string) returns (stream) 
An input stream is created that will return the characters in the given string. If the 
String is non-empty and does not end with a newline, then an extra terminating 
newline will be appended to the stream. 

create_output: proctype () returns (stream) 
An output stream is created that will collect output text in an internal buffer. The 
text may be extracted using the get_contents operation. 

get_contents: proctype (stream) returns (string) signals (not_possible(string)) 


This operation returns the text that has so far been output to the stream. It will 
signal not_possible if the stream was not created by create_out put. 


A stream to a string does not have a file name, a creation date, a maximum line or page 


‘length, or explicit line numbers. 
III.6. Istreams 


Istreams provide the means to read and write image files, and to perform some other 
operations on file objects. The operations allowed on any particular istream depend upon the 


access mode. In addition, certain operations may be null in some implementations. 
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When an operation cannot be performed, because of an incorrect access mode, because of 
implementation limitations, or because of properties of an individual file or device, then the 
operation will signal not_possible (unless the description of the operation explicitly says that the 
invocation will be ignored). 

Actual reading and writing of objects is performed by encode and decode operations of the 
types involved. All of the built-in CLU types, and the filename and date types, provide these 
operations. Designers of abstract types are encouraged to provide them also. The type 


specifications of the encode and decode operations for a type T are: 


encode: proctype (T, istream) signals (not_possible(string)) 


The encode operations are output operations. They write an encoding of the given 
ob ject onto the istream. 


decode: proctype (istream) returns (T) signals (end_of _file, not_possible(string)) 


The decode operations are input operations. They decode the information written by 
encode operations and return an object “similar” to the one encoded. If the sequence 
of decode operations used to read a file do not match the sequence of encode 
operations used to write it, then meaningless objects may be returned. The system 
may in some cases be able to detect this condition, in which case the decode operation 
will signal not_possible("bad format"). The system is not guaranteed to detect all 
such errors. 


The istream operations are: 


open: proctype (file_name, string) returns (istream) signals (not_possible(string)) 


The possible access modes (arg2) are “read”, "write", and “append”. If arg2 is not 
one of these strings, not_possible("bad access mode") is signalled. In those cases 
where the system is able to detect that the specified pre-existing file is not an image 
file, not_possible("wrong file type") is signalled. 


If the mode is “read”, then the named file must exist. If the file exists, an image 
Stream is returned upon which decode operations can be performed. 


If the mode is “write”, a new file is created or an old file is rewritten. An image 
stream is returned upon which encode operations can be performed. 


If the mode is “append”, then if the named file does not exist, one is created. An 
image stream is returned, positioned at the end of the file, upon which encode 
operations can be performed. Append mode to storage files should guarantee 
exclusive access to the file, if possible. 


can_read: proctype (istream) returns (boo!) 


Can_read returns true if decode operations appear possible on the istream. 
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can_write: 


empty: 


reset: 


flush: 


get_date: 


set_date: 


get_name: 


close: 


is_closed: 


equal: 


similar: 


copy: 
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Proctype (istream) returns (bool) 


Can_write returns true if encode operations appear possible on the istream. 


Proctype (istream) returns (bool 


Returns true if and only if there are no more ob jects in the file. 


proctype (istream) signals (not_possible(string)) 

This operation resets the istream so that the next input or output operation will read 
or write the first item in the file. 

proctype (istream) 


Any buffered output is written to the file, if possible. Otherwise, there is no effect. 


proctype (istream) returns (date) signals (not_possible(string)) . 

This operation returns the date of the last modification of the corresponding storage 
file. 

proctype (istream, date) signals (not_possible(string)) 

This operation sets the modification date of the corresponding storage file. (The 
modification date is set automatically when a file is opened in “write” or “append” 
mode.) 

proctype (istream) returns (file_name) 

This operation returns the name of the corresponding file. It may be different than 
the name used to open the file, in that defaults have been resolved and link 
indirections have been followed. 

proctype (istream) 

This operation terminates I/O and removes the association between the istream and 
the file. Further use of operations that signal not_possible will signal not_possible. 
proctype (istream) returns (bool) 


This operation returns true iff the istream is closed. 


proctype (istream, istream) returns (boo) 


Returns true if and only both arguments are the same istream. 


proctype (istream, istream) returns (boo! 


Returns true if and only both arguments are the same istream. 


proctype (istream) returns (istream) 


Returns its argument. 
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III.7. Terminal I/O 


Terminal I/O is performed via streams attached to interactive terminals. Such a stream is 
normally obtained as an argument to the top-level procedure of a program. A terminal stream is 
capable of performing both input and output operations. A number of additional operations are 
possible on terminal streams, and a number of standard operations have special interpretations. 

Terminal! input will normally be buffered so that the user may perform editing functions, such 
as deleting the last character on the current line, deleting the current line, redisplaying the current 
line, and redisplaying the current line after clearing the screen. Specific characters for causing 
these functions are not suggested. In addition, some means must be provided for the user to 
indicate end-of-file, so that a terminal stream can be given to a program that expects an arbitrary 
Stream and reads it until end-of-file. The end-of-file status of a stream is cleared by the reset 
operation. 

Input buffering is normally provided on a line basis. When a program first asks for input 
(using getc, for example) an entire line of input is read from the terminal and stored in an internal 
buffer. Further input is not taken from the terminal until the existing buffered input is read. 

However, new input caused to be read by the getbuf operation will be buffered as a unit. 
Thus, one can read in a large amount of text and allow “editing” of the entire amount of text. In . 
addition, when the internal buffer is empty, the getc_image operation will read a character directly 
from the terminal, without interpreting it or echoing it. 

The user may specify a prompt string to be printed whenever a new buffer of input is 
requested from the terminal; the prompt string will also be reprinted when redisplay of the current 
line is requested by the user. However, if at the time that new input is requested an unfinished 
line has been output to the terminal, then that unfinished line is used instead as a prompt. 

The routine putc_image can be used to cause control functions, eg. ‘\O07 (bell) and ‘\p’ 
(new-page or clear-screen). We cannot guarantee the effect caused by any particular control 
character, but we recommend that the standard ASCII interpretation of contro! characters be 
supported wherever possible. 

Terminal! output may be buffered by the system up to one line at a time. However, the buffer 


must be flushed when new input is requested from the terminal. 
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Terminal streams do not have modification dates. Terminal streams should have file names 
and implicit line numbers. 
Additional operations: 
getbuf: proctype (stream, string) returns (string) 
signals (end_of file, not_possible(string)) 
This operation is the same as gets, except that for terminals with input buffering, 
the entire input read by getbuf is buffered as a unit, allowing input editing of the 
entire text. 
get_prompt: proctype (stream) returns (string) 
This operation returns the current prompt string. The prompt string is initially 
empty (""). The empty string is returned for non-terminal streams. 
set_prompt: proctype (stream, string) 
This operation sets the string to be used for prompting. If not possible, there is no 
ef fect. 
get_input_buffered: proctype (stream) returns (bool) 
This operation returns true iff the stream is attached to a terminal and input ts 
being buffered. 
set_input_buffered: proctype (stream, bool) signals (not_possible(string)) 
This operation sets the input buffering mode. 


get_output_buffered: proctype (stream) returns (boo! 
This operation returns true iff the stream is attached to a terminal and output is 
being buffered. 

set_output_buffered: proctype (stream, boof) signals (not_possible(string)) 


This operation sets the output buffering mode. Unbuffered output is useful for 
programs that output incomplete lines as they are working to allow the user to watch 
the progress of the program. 


III.8. Miscellaneous Procedures 
working dir: proctype () returns (string) © 


This procedure returns the current working directory. A null directory in a file 
name denotes the current working directory. 
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set_working_dir: proctype (string) signals (bad_format, not_possible(string)) 


delete_file: 


rename_f ile: 


user_name: 


now. 


e_form: 


f_form: 


This procedure is used to change the working directory. 


proctype (file_name) signals (not_possible(string)) 


This procedure deletes the specified storage file. Am exception may be signalled 
even if the specified file does not exist, but an exception will not be signalled solely 
because the file does not exist. For example, an exception may be signalled if the 
specified directory does not exist or if the user does not have access to the directory. 


proctype (file_name, filename) signals (not_possible(string)) 


This procedure renames the file specified by argi to have the name specified by 
arg2. Renaming across directories and devices may or may not be allowed. 


proctype () returns (string) 


This procedure returns some identification of the user who is associated with the 
executing process. 


proctype () returns (date) 


This procedure returns the current date and time. 


proctype (real, int, int) returns (string) signals (illegal_field_width) 
E_form returns a real literal of the form: 


[-}_ieta[ f fieldjesx field 
where i_field is arg2 digits, f_field is arg? digits, and x_field is Exp_width digits 
(see Appendix II, Section 4). If arg? = 0, then the decimal point and f_field are not 
present. If arg/ «0.0, then the leftmost digit of i_field is not zero. If arg! = 0.0, 
then x_field is all zeros. Mlegal_field_width occurs if arg2<0 or arg? <0 or 
arg2 + arg3 <1. If necessary, arg! may be rounded to fit the specified form. 


proctype (real, int, int) returns (string) signals (illegal_field_width, 
insufficient_field_width) 


F_form returns a real literal of the form: 


[-} pela f_field 
where f_field is arg? digits. If arg2 >0, then i_field is at least one digit, with 
leading zeros suppressed. If arg2 = 0, then i_field is not present. Illegal_field_width 
occurs if arg2 < 0 or arg? < 0 or arg2 + arg} <1. If necessary, arg! may be rounded 
to fit the = specified form. Insufficient_field_width occurs = if 
real$exponent(arg/) > arg2 after any rounding. 
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g_form: 
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proctype (real, int, int)’ returns (string) signals (illegal_field_width, 
insuf ficient_field_width) 


If arg! = 0.0 or -1 < real$exponent(arg!) < arg2, then the result returned by this 
routine is f_form(argl, arg2, arg3). Otherwise, the result is 
e_form(argl, 1, arg2+arg3-Exp width-3). Illegal_field_width occurs if arg2 <0 or 
arg3 <0 or arg2 + arg? <1. If necessary, arg! may be rounded to fit the specified 
form. Insufficient_field_width occurs if arg! # 0.0 and 
~A-1 < real$exponent(arg!) < arg2) and (arg2 + arg? < Exp_width + 3) after any 
rounding. 


IlII.9. Dates 


Dates are 


are: 


create: 


get_all: 


get_day: 
get_month: 
get_year: 
get_hour: 
get_minute: 
get_second: 


unparse: 


unparse_date: 


unparse_time: 


equal: 


immutable ob jects that represent calendar dates and times. The operations for dates 


proctype (int, int, int, int, int, ind returns (date) signals (bad_format) 


The arguments are (in order) day, month, year, hours, minutes, and seconds. 


proctype (date) returns (int, int, int, int, int, ind 

Returns the components in the same order as given to create. 
proctype (date) returns (int) 

proctype (date) returns (int) 

proctype (date) returns (ind 

proctype (date) returns (int) 


proctype (date) returns (int) 
proctype (date) returns (ind 


(.. 3D, (1. 12), (hd, (0... 23), (0... 59), (0 .. 59), respectively. 


proctype (date) returns (string) 
e.g., “12 January 1978 01:36:59" 


proctype (date) returns (string) 
e.g. “12 January 1978" 


proctype (date) returns (string) 
e.g. "01:36:59" 


proctype (date, date) returns (boo) 
The obvious equal. 
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similar: 


copy: 


Dates $11.9 


proctype (date, date) returns (boo) 
Returns date$equal (argl, arg2). 


proctype (date) returns (date) 


Returns argi. 


proctype (date, date) returns (bool 
proctype (date, date) returns (boo) 
proctype (date, date) returns (bool) 
proctype (date, date) returns (bool 


The obvious relational operations; if date! < date2, then date! occurs earlier than 
date2. 
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Appendix IV - Examples 


IV.1. Priority Queue Cluster . 


This cluster is an implementation of priority queues. It inserts elements in Ollogo n) time, and 
removes the “best” element in O(logy n) time, where n is the number of items in the queue, and 
“best” is determined by a total ordering predicate that the queue is created with. 

The queue is conceptually implemented as a binary tree, balanced such that every element is 
“better” than its descendants, and such that the minimum depth of the tree differs from the 
maximum depth by at most one. The tree is actually represented by keeping the elements in an 
array, with the left son of ali] in alis2), and the right son in alis2+1]. The root of the tree, af1), is 
the “best” element. | 

Each insertion or deletion must rebalance the tree. Since the tree is of depth strictly fess than 
logo n, the number of comparisons is less than logo n for insertion and less than 2 logo n for 
removal of an element. Consequently, a sort using this technique takes less than 37 logon 
comparisons. | 


This cluster illustrates the use of a type parameter, and the use of a procedure as an ob ject. 
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p.queue = cluster [t: type] is create, best, size, empty, insert, remove 


pt = proctype (t, t) returns (boob 
at = arraylt) 
rep = structla: at, p: pt) % 1 <i <= size(a) implies ~p(alil, ali/2)) 


% Create a p_queue with a particular sorting predicate. P should be a transitive, non-reflexive, 
% total order. P(x, y) means that x is better than y. Each element in the p_queue should better 
% than its sons. However, this may not be true if mutable elements are changed while in the 
% p_queue. 


Create = proc (p: pt) returns (cvt 
return(rep${a: at$new(), p: p)) % Low index of array must be 1! 
end create 


% Return the best element. 


best = proc (x: cvt) returns (t) signals (empty) 
return(at$bottom(x.a)) 
except when bounds: signal empty end 
end best 


% Return the number of elements. 
size « proc (x: cv returns (int) 
returmat$size(x.a)) 
end size 
% Return true if there are rio elements. 
empty = proc (x: cv? returns (boo) 


return(atSempty(x.a)) 
end empty 
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% Insert an element of type t. 


insert = proc (x: cvt, v: ft) 


a: at := X.a 

p: pt := X.p 

at$addh(a, v) 

son: int := at$high(a) 

dad: int := son/2 

while dad > 0 cand p(v, aldad]) do 
alson] := aldad] 
son, dad := dad, dad/2 
end 

alson) := v 

end insert 


% Remove the best element and return it. 


remove = proc (x: cv returns (t) signals (empty) 


a: at := X.a 


p: pt := X.p 
r: t := at$bottom(a) 


except when bounds: signal empty end 


v: t := at$remh(a) 
max_son: int := at$size(a) 
if max_son = 0 then return(r) end 
max_dad: int := max_son/2 
dad: int := 1 
while dad <= max_dad do 

son: int := dad*2 

sval: t := alson) 

if son < max_son 

then nsval: t := alson + 1) 


we ah af vf af 2f 


we ee ah af 2 2 2% 


% 
% 


Make room for new item 
Tentative index of v 

Get index of v’s father 
While v better than father 
Move father down 
Get new son, father indexes 


Insert the element into place 


Save best for later return 


Shrink array; save element 
Last son node 


If now empty, we're done 


Last node with a son 
Tentative index of v 
While node has a son 
Get the first son 


If there is a second son 
Find the best son 


if p(nsval, sval) then son, sval := son + 1, nsval end 


end 
if ~p(sval, v) then break end 
aldad) := sval 
dad := son 
end 
aldad] := v 
return(r) 
end remove 


end p_queue 


% 
% 
% 


If son doesn’t beat v, we're done 
Move son up 
Move v down 


Insert the element into place 
Return the previous best element 
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IV.2. Text Formatter 


The following program is a simple text formatter. The input consists of a sequence of | 
unformatted text lines mixed with command lines. Each line (except possibly the fast) is terminated 
by a newline character, and command lines begin with a period to distinguish them f rom text lines. 
For example: 


Justification only occurs in “fill” mode. 

In "nofill" mode, each input text line is output without modification. 
The .br command causes a |ine-break. 

.br 

Just like this. 


The program produces justified, indented, and paginated text. For example: 


Justification only occurs in "fill" mode. In "nofill" mode, 
each input text fine is output without modification. The .br 
command causes a |ine-break. 

Just like this. 


The output text is indented 10 spaces from the left margin, and is divided into pages of 50 text 
lines each. Each output line has 60 characters. A header of 5 lines, including a line giving the 
page number, is output at the beginning of each page. 

An input text fine consists of a sequence of words and word-break characters. The 
word-break characters are space, tab, and newline; all other characters are constituents of words. . 
Tab stops are considered to be every eight spaces. 

Tabs and spaces are accumulated in the current output line along with the input words. Thus, 
if two spaces occur in the input between two words and those words appear on the same output 
line, then they will be separated by at least two spaces. 

The formatter has two basic modes of operation. In “nofill” mode, each input text line is 
output without modification. In “fill” mode, input is accepted until no more words can fit on the 
current output line. Newline characters are treated essentially as spaces. The line is then justified 
by adding extra spaces between words until the last word has its last character in the rightmost 
position of the line. Initially the formatter is in fill mode. 

Justification is performed by enlarging spaces between words, as evenly as possible. Enlarging 
is performed alternately from the right and the left, starting from the right at the top of each page. 
Only spaces to the right of all tabs and between words are subject to justification. Furthermore, 
Spaces preceding the first word following a tab are not subject to justification. If there are no 


Spaces sub ject to justification, then no justification is performed and no error message is produced. 
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In fill mode, any input line that starts with a word-break character causes a line-break: the 
current output line is neither filled nor adjusted, but is output as is. An “empty” input line (one 
Starting with a newline character) causes a line-break and then causes a blank line to be output. 

In nofill mode, if an input line is longer than the line length, it is output as given with no 
error message. In fill mode, if a word is longer than the line length, it is output as given on a line 
by itself with no error message. 


The formatter accepts three different commands: 


-br - causes a line-break 
nf - causes a line-break, and changes the mode to “nofill” 
fi - causes a line-break, and changes the mode to “fill” 


An-unrecognized command name causes an error message and is otherwise ignored. 


The program performs input and output on streams. 
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Fig. 8. Module Dependency Diagram 


Note: boxes with a double line at the top indicate clusters. 
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% Read the instream, processing it and placing the output on outstream and writing error messages 
% on errstream. 


format = proc (instream, outstream, errstream: stream) signals (bad_arg(string)) 
if ~stream$can_read(instream) then signal bad_arg(“input stream”) 
elseif ~stream$can_write(outstream) then signal bad_arg("output stream”) 
elseif ~stream$can_write(errstream) then signal bad_arg(“error stream”) 
end : 
d: doc := doc$create(outstream) 
line: int := 0 
while ~stream$empty(instream) do 
line := line + 1 
do_linelinstream, d) 
except when error (why: string): 
stream$putKerrstream, IntSunparse(line) Ml ":\t" fl why) 


end 
end 
doc$terminate(d) 
end format 


% Process an input line. The line is processed either as a text line or as a command tine, | 
% depending upon whether or not the first character of the line is a period. 


do_line = proc (instream: stream, d: doc) signals Aerocistriny 

c: char := stream$peekc(instream) 
few’ 

then do_command(instream, d) 

resignal error 

else do_text_linelinstream, d) 

end 
end do_line 
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% Process a command line. This procedure reads up to the first space or tab in a line and 
% processes the string read as a command. The remainder of the line is read and discarded. 


do_command = proc (instream: stream, d: doc) signals (error(string)) 
stream$getclinstream) . % skip the period 
n: string := stream$gets(instream, “ \t\n") 
except when end_of _file: n := ” end 
Stream$getK instream) % read and discard remainder of input tine 
except when end_of _file: end 
ifn = “br® then doc$break_line(d) 
elseif n = “fi” then doc$set_filKd) 
elseif n = “nf” then doc$set_nofilKd) 
elseif n = ~ then signal error("missing command”) 
else signal error(“" nf” not a command? 
end ; 
end do_command 


% Process a text line. This procedure reads one line from instream and processes it as a text line. 
% If the first character is a word-break character, then a line-break is caused. If the line is empty, 
% then a blank line is output. Otherwise, the words and word-break characters in the line are 
% processed in turn. 


do_text_line = proc (instream: stream, d: doc) 
c: char := stream$getclinstream) 
eo=\n’ : 
then doc$skip_line(d) % empty input line 
return 
elseifc='* cor c= \t 
then doc$break_line(d) . 
end 
while c ~= ‘\n’ do 
tc =’* then doc$add_space(d) - 
elself c = ‘\t’ then doc$add_tab(d) 
else w: word := word$scanic, instream) 
doc$add_word(d, w) 
end 
C := stream$getclinstream) 
end except when end_of file: end 
doc$add_newline(d) 
end do_text_line 
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The doc cluster implements documents, the properly indented, justified, and paginated output of 
the text formatter. A document is constructed incrementally, using operations to add words, 
Spaces, tabs, and newlines to the end of the document. Other operations are used for the basic 
formatting actions: break_line to cause a line break, skip_line to output a blank line, set_fill and 
set_nofill to set the formatting mode. Rather than collecting the entire document as a sequence 
of lines before outputting to a file, each line is output as it is produced. The current output line 
is maintained for the purposes of performing justification. To perform pagination and the 
production of headings, the current line number and the current page number are also 
maintained. 


we we ze vl ve ze Pe Zh 7h 


doc = cluster fs create, add_word, add_space, add_tab, add_newline, 
break _line, skip_line, set_fill, set_nofill, terminate 


rep-recordiline. _ line, % The current line. 
fill: bool, % True <==> in fill mode. 
rk: bool, % True <==> justify next line right-to-left. 
lineno: int, % The number of lines output so far on this page - 
% (not including any header lines). 
pageno: _int, % The number of the current output page. 
outstream: stream] % The output stream. 


chars_per_line = 60 
lines_per_page = 50 
left_margin_size = 10 


% Create a doc object. The first page is number 1, there are no lines yet output on it. Fill mode ts. 
% in effect. 


create = proc (outstream: stream) returns (cv® 


returnrep${line: lineScreate(), 
fitt: true, 
r2t: true, 
lineno: 0, 
pageno: |, 


outstream: outstream)) 
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Process a word. This procedure adds the word W to the output document. If in nofill mode, 
then the word is simply added to the end of the current line (there is no line-length checking in 
nofill mode). If in fill mode, then we first check to see if there is room for the word on the 
current line. If the word will not fit on the current line, we first justify and output the line and 
then start a new one; justification is performed alternately from the right and the left on 
successive lines. However, if the line is empty, then we just add the word to the end of the line; 
if the word won't fit on an empty line, then it won't fit on any line, so we have no choice but to 
put it on the current line, even if it doesn’t fit. 


we ve 2h vk af 2f af ae 


add_word = proc (d: cvt, w: word) 
if d.fill cand ~lineSempty(d.line) 
then If lineSlength(d.tine) + word$width(w) > chars_per_line 
then line$ justif y(d.line, ‘chars_per_tine, d.r20 ; 
d.r2l := wd.r2t- 
output_tinetd) 
end 
end 
line$add_word(d. tine, w) 
end add_word. 


- % Process a space -- just add it to the current line. 


add_space = proc (d: cv 
lineSadd_space(d.line) 
end add_space 


% Process a tab -- just add it to the current line. 


add_tab = proc (d: ev® 
line$add_tab(d.line) 
end add_tab 


% Process a newline. It in nofifl mode, then the current line sane as is. Otherwise, a newline 
% is treated just like a space. 


add_newline = proc (d: cv 
 1¢ ~d.fill 
then outputtineld) ts 
else lineSadd_space(d_tine) 
end 
end add_newline 
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% Cause a line break. If the line is not empty, then it is output as is. Line breaks have no effect 
% on empty lines -- multiple line breaks are the same as one. 


break_line = proc (d: cvt) 
if ~lineSempty(d.line) then output_line(d) end 
end break_line 


% Cause a line break and output a blank line. 


skip_line = proc (d: cvt 

break_line(up(d)) 

output_line(d) % line is empty 
end skip_line 


% Cause a line break and enter fill mode. 


set_fill = proc (d: cv0 
break_line(up(d)) 
d fill := true 
end set_fill 


% Cause a line break and enter nofill mode. 


set_nofill = proc (d: cvt) 
break_line(up(d)) 
d fill :< false 
end set_nofill 


% Terminate the output document. 
terminate = proc (d: cv) 


break_linefup(d)) — 
end terminate 
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% Internal routine. 


% Output line is used to keep track of the line number and the page number and to put out the 
% header at the top of each page. At the top of each page, justification is reset to start from the 
% right. 


output_line = proc (d: rep) 
if d.lineno = 0 
then if d.pageno > 1 
then stream$putc(d.outstream, \p’) end 
stream$puts(d.outstream, “\n\n") % print header 
stream$putspace(d.outstream, left_margin_size) 
stream$puts(d.outstream, "Page ") 
stream$puts(d.outstream, intSunparse(d.pageno)) 
stream$puts(d.outstream, “\n\n\n") 
end 
d.lineno := d.lineno + 1 
if ~line$empty(d.line) 
then stream$ putspace(d.outstream, left_margin_size) 
line$output(d.line, d.outstream) 
end 
stream$putc(d.outstream, ‘\n’) 
if d.lineno = lines_per_page 
then d.r2l := true 
d.lineno := 0 
d.pageno := d.pageno + 1 
end 
end output_line 


end doc 
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% 
% 
* 
% 
% 
x 
% 
% 
% 


A line is a mutable sequence of words, spaces, and tabs. The length of a line is the number of 
character positions that would be used if the line were output. One may output a line onto a 
stream, in which case the line is made empty after printing. One may also justify a line to a 
given length, which means that some spaces in the line will be enlarged to make the length of 
the line equal to the desired length. .Only spaces to the right of all tabs are subject to 
justification. Furthermore, spaces preceding the first word in the output line or preceding the 
first word following a tab are not subject to justification. 
justification or if the line is too long, then no justification is performed and no error message is 


produced. 


Text Formatter 


line = cluster is create, add_word, add_space, add_tab, length, empty, justify, output 


token = variant{space: int, % 
tab: int, % 
word: word] 


at = arrayltoken) 
rep = record length: int, % 


stuff: at] % 
% 
max_tab_width = 8 % 


% Create an empty line. 


create = proc 0 returns (cv® 


% 


return(rep${length: 0, 
suff: at$new())) 
end create 


Add a word at the end of the line. 


add_word = proc (I: cvt, w: word) 


% Add a space at the end of the line, combining it with an existing trailing space, if any. 


atS$addh(Lstuff, token$make_word(w)) 


the int is the width of the space 
the int is the width of the tab 


the current length of the line 
the contents of the line 
no two adjacent tokens will both be spaces 


maximum chars per tab 


Llength := Llength + word$width(w) 


end add_word 


add_space . proc (I: cvt 


I.length := Llength + 1 
tagcase at$top(I.stuff) 


tag space (width: int: token$change_space(at$top(I.stuff), width + 1) 
return 


others: 


end except when bounds: end % Handle empty array case. 
at$addh(Lstuff, token$make_space(1)) 


end add_space 


If there are no spaces subject to 
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% Add a tab at the end of the line. 


add_tab = proc (I: cvt) 
width: int := max_tab_width - (length // max_tab_width) 
Liength := Llength + width - 
atSaddh(L stuff, token$make_tab(width)) 
end add_tab 


% Return the current length of the line. 


length = proc (I: cvt returns (ind 
return(l.length) 
end fength 


% Return true if the line is of length zero. 


empty = proc (I: cv returns (boo) 
returniliength = 0) 
end empty 


Justify the line, if possible, so that it’s length is equal to LEN. Before justification, any trailing 
Space is removed. If the line length at that point is greater or equal to the desired length, then 
no action is taken. Otherwise, the set of justifiable spaces is found, as described above. If there 
are no justifiable spaces, then no further action is taken. Otherwise, the justifiable spaces are 
enlarged, as evenly as possible, to make the line length the desired length. Enlarging is 
performed either from the right or the left, depending on R2L. 


ve vl af af ae af 


pstify = proc (I: cvt, len: int, r2I: boo) 
tagcase at$top(I.stuff) 
tag space (width: int): at$remh(1.stuff) 
Liength := Llength - width 
others: 
end except when bounds: end % Handle empty array case. 
. if length >= len then return end 
diff: int := len - Llength 
first: int := find _first_justifiable_space(1) 
except when none: return end 
enlarge_spaces(|, first, diff, r20 
end justify 
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x Output the line and reset it. 


output = proc (I: cvt, outstream: stream) 
for t: token in at$elements(I.stuff) do 
tagcase t p 
tag word (w: word): word$output(w, outstream) 
tag space, tab (width: Int): stream$putspace(outstream, width) 
end 
end 
\.length := 0 
at$trim(istuff, Lt, 0) 
end output 


2 


Internal routines. 


Find the first justifiable space. This space is the first space after the first word after the last 
tab in the line. Return the index of the space in the array. Signal NONE if there are no 
justifiable spaces. Although no two adjacent tokens will both be words (as lines are currently 
used), no such assumption is made here. 


we ve ae 2h 


find_first_justifiable_space = proc (I: rep) returns (int) signals (none) 

a: at := Lstuff , 

if atS$empty(a) then signal none end 

lo: int := at$low(a) 

hi: int := at$high(a) 

i: int := hi 

while i >1o cand ~token$is_tab(ali]) do % find last tab in the line (if any) 
i:=i-1 
end 

while i <= hi cand ~token$is_word(ali]) do % find first word after it (or first in line) 
i:=i+1 
end 

while i <= hi cand ~tokenSis_space(ali]) do % find first space after that 
i:swi+] 
end 

if i > hi then signal none end 

return(i) 

end find_first_justifiable_space 
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% Enlarge the spaces in the array whose indexes are at least FIRST. Add a total of DIFF extra 
% character widths of space. Add spaces working from the right or the left, depending on R2L. 


enlarge_spaces = proc (I: rep, first, diff: int, r2I: boo) 

nspaces, last: int := count_spaces(I, first) 
if nspaces = 0 then return end 
by: int := 1 
if r2t 

then by := -1 

first, fast := last, first 

end 
neach: int := diff / nspaces % Amount to increase each space. 
nextra: int := diff // nspaces % Leftovers to be distributed. 
for i: int in int$from_to_by(first, last, by) do 

tagcease I stuf fli) 

tag space (width: ind: width := width + neach 
if nextra > 0 
then width := width + 1 
nextra := nextra - 1 


end 
token$change_space(|.stuf fli}, width) 
others: 
end 
end 


Ilength := Llength + diff 
end enlarge_spaces 


%. Return a count of the number of spaces in the line whose indexes in the array are at least IDX, 
'% and return the index of the last space counted. 


count_spaces = proc (I: rep, idx: int) returns (int, Ind 
count: int := 0 
for i: int in int$from_tolidx, atShigh(1.stuff)) do 
tagcase I.stuf fli) 
tag space: count := count + 1 


idx :=i 
others: 
end 
end 
return(count, idx) 


end count_spaces 


end line 
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% A word is an item of text. It may be output to a stream. It has a width, which ts the number of 
% character positions that are taken up when the word is printed. 


word = cluster Is scan, width, output 
rep = string 


% Construct a word whose first character is C and whose remaining characters are to be removed 
% from the instream. 


scan = proc (c: char, instream: stream) returns (cv 
s: string := string$c2s(c) 
S := $ Il stream$gets(instream, “ \t\n") 
except when end_of_file: end 
return(s) 
end scan 


% Return the width of the word. 

width = proc (w: cv? returns (ind 
return string$size(w)) 
end width 

% Output the word. 

output = proc (w: cvt, outstream: stream) 
stream$puts(outstream, w) 


end output 


end word 
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IV.3. Text Substitution Program 


The following (rather complex) program performs textual substitutions of one set of strings 
for another throughout a file. It can be useful in expanding abbreviations, renaming variables, 
correcting misspellings, etc. 

Substitutions are specified by a list of rules read from a file. Each rule consists of a 
left-hand-side (the string to be replaced) and a right-hand-side (the string to replace with), 


separated by a ‘>’ character. Each rule is terminated by a newline character. For example, to 
substitute "BEGIN" for “begin” and "END" for “end”, the rules would be: 


begin>BEGIN 
end>END 


All substitutions are done simultaneously, so for example it is possible to substitute “a” for “b" 
and “b" for “a”. Substitution is not performed on the results of a substitution, only on the original 
text. When performing substitutions, the rule with the longest left-hand-side always takes 
precedence. Thus, given the two rules: 


abc>x 
ary 


an input of “abcab” would be transformed to "xyb". 

Within a rule, characters can be represented with the same escape sequences allowed in string 

literals. For example, the following rule replaces each newline by two newlines: 
\n>\n\n 
In addition, the escape sequence “\>" can be used to represent the character ">". 

The program asks for the name of a rule file, and then loops asking for pairs of input and 
output file names to process using the given rules. If no input file is given, a new rule file is 
‘requested. If no rule file is given, the program terminates. If no output file is given, a new input 
file is requested. 

The program is implemented using a pushdown transducer: a pushdown automaton extended 


to produce output. 
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Fig. 9. Module Dependency Diagram 


all_suffix_states 


Note: boxes with a double line at the top indicate clusters. 
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% Ask for a rule file and build a pushdown transducer for it, and then loop asking for pairs of 
% input and output files and processing them using that pushdown transducer. When no input 
% file is given, ask for a new rule file. When no rule file is given, terminate. When no output 
% file is given, ask for a new input file. 


substitute = proc () 
tyo: stream := stream$primary_output() 
while true do 
rst: stream := get_stream("rule file: “, “read") 
except when refused: return end 
m: pdt := build_pdt(rst) , 
except when illegal (line: int, why: string): 


stream$close(rst) 
stream$putKtyo, ee WAC Hl why) 
continue 
end 
stream$close(rst) 
while true do 


inst: stream := get_stream("input file: ", “read”? 
except when refused: break end 

outst: stream := get_stream("output file: ", "write" 
except when refused: stream$close(inst) 

continue 
end 

run_pdt(inst, outst, m) 

stream$close(outst) 

stream$close(inst) 

end 

end 
end substitute 


sIV.3 Text Substitution Program 157 


% Read in a filename and open the file in the given mode. Signal refused if no filename is 
% given. 


get_stream = proc (prompt, mode: string) returns (stream) signals (refused) 
tyi: stream := stream$primary_input() 
tyo: stream := stream$primary_output() 
tyi.input_buffered := true 
while true do 
stream$puts(tyo, prompt) 
fs: string := stream$getKtyi) 
If stringSempty(fs) 
then signal refused end 
return stream$open(file_name$parse(fs), mode)? 
except when bad_format: stream$putKtyo, “bad format file name”) 
when not_possible (s: string): stream$putltyo, s) 
end 
end except when end_of_file: signal refused end 
end get_stream 


% Read and parse the rules from the sven stream. Construct and return a pushdown transducer 
% corresponding to those rules. 


build_pdt = proc (st: stream) returns (pdt) signals (illegaKint, string)) 
rule = struct{left, right: string) 
rulelist = arrayfrule) 
rules: rulelist := rulelist$new() 
line: int := 1 
while true do 
while stream$peekc(st) = '\n’ do 
stream$getc(st) 
line := fine + 1 
end except when end_of_file: return(pdt$create(rules)) end 
left: string := get_rule_part(st, “>\n") 
if stringSempty(left) 
then signal iflegal(line, “missing left side of rule) end 
if stream$empty(st) cor stream$getc(st) wn’>' 
then signal illegal(line, "missing right side of rule”) end 
right: string := get_rule_part(st, “\n") 
rulelist$addh(rules, rule${left: left, right: right} 
end except when illegal (why: string): signal illegalline, why) end 
end build_pdt 
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% Parses a rule part up to but not including the given terminators. Accepts the regular escape 
% sequences, plus “\>” to represent ">" 


get_rule_part = proc (st: stream, terms: string) returns (string) signats (illegaX string) 
terms := string$append(terms, '\\ 
part: string := ™ 
while true do 
begin 
part := part ll stream$gets(st, terms) 
if stream$peekc(st) ~= "\\’ 
then return(part) end 
end except when end_of file: raiwernipiat end 
c: char := streamSgetc(st) 
x: int := strings indexc(stream$peekc(st), “\"\\ontpbrv*? 
fx >0 
then stream$getc(st) 
crs “N\\o\n\t\p\b\r\v Tx] 
else sum: int := 0 
for i: int in Int$from_to(l, 3) do 
C := stream$getc(st) 
ifc<'0 cor c>T 
then exit illegal_char end 
sum so smh ¢ 8 + cherSC2KO - char$c2K'0) 
end 
c := char$i2c(sum) 
end 


part := stringSappend(part, Q 
end 


except when end_of _file, illegal_char: signal mere escape sequence’) 
end 
end get_rule_part 


% Perform all substitutions on a file. 


run_pdt = proc (inst, outst: stream, m: pdt) 
, while true do 
pdt$move(m, stream$getc(inst)) 
except when output (s: string): stream$puts(outst, ) end 
end except when end_of _file: nies peroeet cares end 
end run_pdt 
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% 
% 
% 
% 
% 
% 
x 
% 


A pushdown transducer is a collection of states connected by transitions. A transition can also 
connect a state to an output condition, with the initial state as the implicit next state. A 
transition is labeled with both an input character and a set of lookahead characters; the 
transition is to be followed if the current input character matches and the current lookahead 
character is in the lookahead set. The basic operation of the transducer is move, which moves 
according to the current input character (at the top of the pushdown list), and the current 
lookahead character (given as an argument). Output is produced by signalling with a string 
result. 


pdt = cluster is create, move, reset 


we 2h af af af ze 


rep = record first: state, % initial state 
buffer: buf, % path from initial state to current state 
% plus next input char 
current: state] % current state 


rule = structlleft, right: string] 
rutelist = arraylrule) 
buf = arrayl char) 


Two phase construction. First construct all states and transitions needed to follow any single 
rule from the initial state to its output condition. Then fill in missing cross-transitions for rules 
that interact with each other, in (approximately) the following manner. For each substring of a 
left-hand side of a rule (a path from some state $3 to some state $2) that is also a prefix of a 
left-hand side of a rule (a path from the initial state to some state SI), add all transitions out of 
S1 (not conflicting with existing transitions out of S2) as transitions out of S2. 


create = proc (rules: rulelist) returns (cvt) signals (illegal string)) 


first: state := state$create() 
for r: rule in rulelist$elements(rules) do 
add_rule(first, r) 
end resignal illegal 
for path: string, s2: state in all_states(first) do 
for sl: state in all_suffix_states(path, first) do 
replicate(sl, s2) 
end 
end 
returmrep${first: first, buffer: buf$new0, current: first}) 
end create 
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Make a move with the given char as the lookahead input. If a rule is recognized (an output 
condition is reached), the left side of the rule is discarded from the end of the buffered input, 
and any remaining input is concatenated with the right side of the rule and returned for output. 
If no rule can match the current buffered input, the entire buffered input is returned for 
output. 


ae a af 2: at 


move = proc (m: cvt, peek: char) signals (output(string)) 
m.current := stateSmove(m.current, buf$top(m.buffer), peek) 
except when output (size: int, out: string): 
buf$trim(m.buffer, 1, buf$size(m.buffer) - size) 
out := resetl(m) fi out 
buf$addh(m.buffer, peek) 
signal output(ou) 
when no_match: 
out: string := resetl(m) 
buf$addh(m.buffer, peek) 
signal output(out) 
when bounds: 
. end 
buf $addh(m_.buf fer, peek) 
end move 


% Force input termination. Returns any final output. Restores the pdt to its initial state. 


reset = prac (m: cvd returns (string) 
extra: string := ™ 
m.current := stateS$movel(m.current, buf$top(m.buffer)) 
excent when output (size: int, out: string): 
buf$trim(m.buffer, 1, buf ssize(m buffer) - size) 
extra := out 
when no_match, bounds: 
. end 
return reseth(m) fl extra) 
end reset 


_ % Internal routine. 
% Return current buffered input. Reset current state to initial state. 


reset] = proc (m: rep) returns (string) 
S$: string := string$ac2s(m.buffer) 
buf $trim(m.buffer, 1, 0 
m.current := m_first 
returns) 
end reseti 


end pdt 
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% Add a new rule. Follow existing path through pdt as far as possible, and then add new states. 
% Just add states and transitions needed to follow the rule from the initial state to the output 
% condition, do not add cross-transitions for interacting rules. 


add_rule = proc (s: state, r: rule) signals (illegal string)) 

rule = structfleft, right: string) 
left: string := r.left 
if stringSempty(left) 

then signal illegaK"rule has empty left side) end 
size: int := string$size(left) 
i: int := 1 
peeks: string := 
while i < size do 

S := State$movets, feftlil, leftli + 1)) 

izeiel] 

end except when output (#): peeks := string$c2s(leftli + 1)) 

when no_match: 
end 

while i < size do 

ns: state := state$create() 

state$add_move(s, leftli], peeks, ns) 

S:= Ns 

i:xi+l 

peeks ;= “" 

end 
state$add_output(s, left{sizel, size, r.right) 

except when illegal: signal illegal “conflicting rules’) end 
end add_rule 


% Traverse depth first left to right, yielding all path-state pairs reachable from given state. Depth 
% first traversal is used to satisfy the requirement that the rule with the longest left-hand side 
% takes precedence. 


all_states = tter (s: state) yields (string, state) 
for input: char, peeks: string, next: state In stateSall_moves(s) do 
pre: string := string$c2s(input) 
for path: string, ns: state in all_states(next) do 
yleidpre Il path, ns) 
end 
yleld(pre, next) 
end 
end all_states 
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% Given a string, follow all proper suffixes (longest first) of the string as paths from the given 
% state, and yield the final state reached by each legal path. The suffixes are done longest first to 
% satisfy the requirement that the rule with the longest feft-hand side takes precedence. 


all_suffix_states = iter (path: string, first: state) ylelds (state) 
size: int := string$size(path) 
for i: int in int$from_tol2, size) do 
S: state := first 
f int :=i 
while j < size do 
S := State$movels, pathl j), pathl j + 1) 
j= j+l 
end except others: continue end 
$ := state$movel(s, pathl j)) 
except others: continue end 
yields) 
end 
end all_suffix_states 


% For each input char causing a transition out of SI but not causing a transition out of S2, add a 
% transition out of S2. 


replicate = proc (si, s2: state) 
for input: char, peeks: string, s: state in stateSall_movessD do 
state$movel(s2, input) 
except when output (): continge 
when no_match: 
end 
state$add_move(s2, input, peeks, 3) 
except others: end 
end 
for input: char, size: int, out: string in sat open do 
state$add_output(s2, input, size, out) _ 
except others: end 
end 


end replicate 
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% 
* 
% 
% 
% 
x 


A state is a collection of arcs, each labeled with the input character required to take the 
transition. An arc either points to a new state, or indicates an output condition (with the initial 
State as the implicit new state). For arcs to new states, a list of acceptable lookahead characters is 
also present, with an empty list indicating “all others”. An output condition implicitly carries an 
“all others” lookahead list. There are operations to add new transitions, iterate over the 
transitions, and move to a new state given the current input and lookahead. 


state = cluster Is create, all_moves, add_move, all_outputs, add_output, move, movel 


rep = array(trans) % a state is a set of transitions 
trans = structlinput: char, % a transition is a labeled arc 
next: arc] 
arc = oneoffstate: _pstate, % an arc is to a new state 
output: output) % or to an output condition 

pstate = record{peeks: string, % empty lookahead means “all others” 

state: state) 
output = structlsize: int, % size of left side of rule 

out: string) % right side of rule 


% implicit “all others” lookahead 


% Create a new state with no transitions. 


create = proc () returns (cv) 


return rep$new()) 
end create 


% Yield all transitions (input, lookaheads, next state) from the given state to new states. 


all_moves = iter (s: cvt) yields (char, string, state) 


for t: trans in rep$elements(s) do 
tagcase t.next 
tag state (ps: pstate): yield(t.input, ps.peeks, ps.state) 
tag output: 
end 
end 
end all_moves 
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% Add a transition from one state to another for the given input and that subset of the given list 
% of lookahead chars not present on existing transitions for the given input. The addition is 
% illegal if all of the lookaheads are already accounted for by existing transitions. An empty 
% lookahead list denotes “all others not specified on other transitions for the same input”. 


add_move = proc (from: cvt, input: char, peeks: string, to: state) signals (illegal 
rpeeks: string := peeks 
for t: trans In rep$elements(from) do 
if t.input = input 
then tagcase t.next 
tag state (ps: pstate): If stringSempty(ps.peeks) 
then signal illegal 
else rpeeks := strip(rpeeks, ps.peeks) 
» end 
tag output: If stringSempty(peeks) 
then signal illegal end 
end 
end 
end 
If stringSempty(rpeeks) cand ~string$empty(peeks) 
then signal illegal end 
rep$addKfrom, trans${input: input, 
next: arc$make_state(pstate${ peeks: peeks, 
state: to}))) 
end add_move ; 


% Yield all transitions (input, size, output) from the given state to output conditions. 


afl_outputs = Iter (s: cvt) yields (char, int, string) 
for t: trans in rep$elements(s) do 
tagcase t.next 
tag state: 
tag output (x: output): yleld{t.input, x.size, x.out) 
end 
end 


end all_outputs 
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% Add a transition from the given state to an output condition for the given input. An “all 
% others” lookahead list is implicit for this transition, so the addition is illegal if a transition for 
% the given input and an “all others” lookahead list already exists. 


add_output = proc (from: cvt, input: char, size: int, out: string) signals (illegal) 
for t: trans in rep$elements(from) do 
if t.input = input 
then tagcase t.next 
tag state (ps: pstate): 

if ~stringSempty(ps.peeks) 
then continue end 

peeks: string := 

for x: trans in rep$elements(down(ps.state)) do 
peeks := stringSappend(peeks, x.input) 


end 
ps.peeks := peeks 
tag output: — 
signal illegal 
end 
end 
end 


repSaddh(from, trans${input: input, 
next: arc$make_outputloutput${size: size, 
out: out})}) 


end add_output 


% Return the next state for the given input and lookahead. Signal no_match if no transition is 
% possible. Signal output if an output condition is reached. 


move = proc (s: cvt, input, peek: char) returns (state) signals (no_match, output(int, string)) 
for t: trans in rep$elements(s) do 
if t.input = input 
then tagcase t.next 
tag state (ps: pstate): 
if stringSempty(ps.peeks) cor stringSindexc(peek, ps.peeks) > 0 
then return(ps.state) end 
tag output (x: output): 
signal output(x.size, x.out) 
end 
end 
end 
signal no_match 
end move 
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% Return the next state for the given input with no further input available. Signal no_match if 
% no transition is possible. Signal output if an output condition is reached. 


movel = proc (s: cvt, input: char) returns (state) signals (no_match, output(int, string)) 


for t: trans in repSelements(s) do 
if t.input = input 
then tagcase t.next 
tag state (ps: pstate): If stringSempty(ps.peeks) 
then return(ps.state) end 
tag output (x: output): signal output(x.size, x.out) 
end 
end 
end 
signal no_match 
end movel 


end state 

% Remove chars in USING from chars in FROM. 

strip = proc (from, using: string) returns (string) 
for c: char in string$chars(using) do 


i: Int := stringSindexc(c, from) 
fio 


then from := string$substr(from, 1, i - 1) I stringSrest(from, i+ D end 


end 
return from) 
end strip 
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